Linux 4.14.330

 
ACPI: sysfs: Fix create_pnp_modalias() and create_of_modalias() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Mon Oct 23 20:32:54 2023 +0200

    ACPI: sysfs: Fix create_pnp_modalias() and create_of_modalias()
    
    [ Upstream commit 48cf49d31994ff97b33c4044e618560ec84d35fb ]
    
    snprintf() does not return negative values on error.
    
    To know if the buffer was too small, the returned value needs to be
    compared with the length of the passed buffer. If it is greater or
    equal, the output has been truncated, so add checks for the truncation
    to create_pnp_modalias() and create_of_modalias(). Also make them
    return -ENOMEM in that case, as they already do that elsewhere.
    
    Moreover, the remaining size of the buffer used by snprintf() needs to
    be updated after the first write to avoid out-of-bounds access as
    already done correctly in create_pnp_modalias(), but not in
    create_of_modalias(), so change the latter accordingly.
    
    Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    [ rjw: Merge two patches into one, combine changelogs, add subject ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ARM: 9321/1: memset: cast the constant byte to unsigned char [+ + +]
Author: Kursad Oney <kursad.oney@broadcom.com>
Date:   Tue Aug 22 15:06:06 2023 +0100

    ARM: 9321/1: memset: cast the constant byte to unsigned char
    
    [ Upstream commit c0e824661f443b8cab3897006c1bbc69fd0e7bc4 ]
    
    memset() description in ISO/IEC 9899:1999 (and elsewhere) says:
    
            The memset function copies the value of c (converted to an
            unsigned char) into each of the first n characters of the
            object pointed to by s.
    
    The kernel's arm32 memset does not cast c to unsigned char. This results
    in the following code to produce erroneous output:
    
            char a[128];
            memset(a, -128, sizeof(a));
    
    This is because gcc will generally emit the following code before
    it calls memset() :
    
            mov   r0, r7
            mvn   r1, #127        ; 0x7f
            bl    00000000 <memset>
    
    r1 ends up with 0xffffff80 before being used by memset() and the
    'a' array will have -128 once in every four bytes while the other
    bytes will be set incorrectly to -1 like this (printing the first
    8 bytes) :
    
            test_module: -128 -1 -1 -1
            test_module: -1 -1 -1 -128
    
    The change here is to 'and' r1 with 255 before it is used.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Kursad Oney <kursad.oney@broadcom.com>
    Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ARM: dts: qcom: mdm9615: populate vsdcc fixed regulator [+ + +]
Author: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Date:   Sun Sep 24 20:39:13 2023 +0200

    ARM: dts: qcom: mdm9615: populate vsdcc fixed regulator
    
    [ Upstream commit 09f8ee81b6da5f76de8b83c8bfc4475b54e101e0 ]
    
    Fixed regulator put under "regulators" node will not be populated,
    unless simple-bus or something similar is used.  Drop the "regulators"
    wrapper node to fix this.
    
    Fixes: 2c5e596524e7 ("ARM: dts: Add MDM9615 dtsi")
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20230924183914.51414-3-krzysztof.kozlowski@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: Intel: Skylake: Fix mem leak when parsing UUIDs fails [+ + +]
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date:   Thu Oct 26 10:25:58 2023 +0200

    ASoC: Intel: Skylake: Fix mem leak when parsing UUIDs fails
    
    [ Upstream commit 168d97844a61db302dec76d44406e9d4d7106b8e ]
    
    Error path in snd_skl_parse_uuids() shall free last allocated module if
    its instance_id allocation fails.
    
    Fixes: f8e066521192 ("ASoC: Intel: Skylake: Fix uuid_module memory leak in failure case")
    Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
    Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
    Link: https://lore.kernel.org/r/20231026082558.1864910-1-amadeuszx.slawinski@linux.intel.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: use u64 for buffer sizes in the tree search ioctls [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Fri Oct 13 10:05:48 2023 +0100

    btrfs: use u64 for buffer sizes in the tree search ioctls
    
    [ Upstream commit dec96fc2dcb59723e041416b8dc53e011b4bfc2e ]
    
    In the tree search v2 ioctl we use the type size_t, which is an unsigned
    long, to track the buffer size in the local variable 'buf_size'. An
    unsigned long is 32 bits wide on a 32 bits architecture. The buffer size
    defined in struct btrfs_ioctl_search_args_v2 is a u64, so when we later
    try to copy the local variable 'buf_size' to the argument struct, when
    the search returns -EOVERFLOW, we copy only 32 bits which will be a
    problem on big endian systems.
    
    Fix this by using a u64 type for the buffer sizes, not only at
    btrfs_ioctl_tree_search_v2(), but also everywhere down the call chain
    so that we can use the u64 at btrfs_ioctl_tree_search_v2().
    
    Fixes: cc68a8a5a433 ("btrfs: new ioctl TREE_SEARCH_V2")
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/linux-btrfs/ce6f4bd6-9453-4ffe-ba00-cee35495e10f@moroto.mountain/
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: keystone: pll: fix a couple NULL vs IS_ERR() checks [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Thu Oct 5 17:01:57 2023 +0300

    clk: keystone: pll: fix a couple NULL vs IS_ERR() checks
    
    [ Upstream commit a5d14f8b551eb1551c10053653ee8e27f19672fa ]
    
    The clk_register_divider() and clk_register_mux() functions returns
    error pointers on error but this code checks for NULL.  Fix that.
    
    Fixes: b9e0d40c0d83 ("clk: keystone: add Keystone PLL clock driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/d9da4c97-0da9-499f-9a21-1f8e3f148dc1@moroto.mountain
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Fri Sep 1 10:46:58 2023 +0800

    clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
    
    [ Upstream commit 0d6e24b422a2166a9297a8286ff2e6ab9a5e8cd3 ]
    
    Add the check for the return value of mtk_alloc_clk_data() in order to
    avoid NULL pointer dereference.
    
    Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20230901024658.23405-1-jiasheng@iscas.ac.cn
    Reviewed-by: Markus Schneider-Pargmann <msp@baylibre.com>
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data [+ + +]
Author: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Date:   Tue Sep 12 17:34:05 2023 +0800

    clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
    
    [ Upstream commit 606f6366a35a3329545e38129804d65ef26ed7d2 ]
    
    Add the check for the return value of mtk_alloc_clk_data() in order to
    avoid NULL pointer dereference.
    
    Fixes: 96596aa06628 ("clk: mediatek: add clk support for MT6797")
    Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20230912093407.21505-3-jiasheng@iscas.ac.cn
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: clk-rcg2: Fix clock rate overflow for high parent frequencies [+ + +]
Author: Devi Priya <quic_devipriy@quicinc.com>
Date:   Fri Sep 1 13:06:40 2023 +0530

    clk: qcom: clk-rcg2: Fix clock rate overflow for high parent frequencies
    
    [ Upstream commit f7b7d30158cff246667273bd2a62fc93ee0725d2 ]
    
    If the parent clock rate is greater than unsigned long max/2 then
    integer overflow happens when calculating the clock rate on 32-bit systems.
    As RCG2 uses half integer dividers, the clock rate is first being
    multiplied by 2 which will overflow the unsigned long max value.
    Hence, replace the common pattern of doing 64-bit multiplication
    and then a do_div() call with simpler mult_frac call.
    
    Fixes: bcd61c0f535a ("clk: qcom: Add support for root clock generators (RCGs)")
    Signed-off-by: Devi Priya <quic_devipriy@quicinc.com>
    Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
    Link: https://lore.kernel.org/r/20230901073640.4973-1-quic_devipriy@quicinc.com
    [bjorn: Also drop unnecessary {} around single statements]
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dccp/tcp: Call security_inet_conn_request() after setting IPv6 addresses. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Mon Oct 30 13:10:42 2023 -0700

    dccp/tcp: Call security_inet_conn_request() after setting IPv6 addresses.
    
    [ Upstream commit 23be1e0e2a83a8543214d2599a31d9a2185a796b ]
    
    Initially, commit 4237c75c0a35 ("[MLSXFRM]: Auto-labeling of child
    sockets") introduced security_inet_conn_request() in some functions
    where reqsk is allocated.  The hook is added just after the allocation,
    so reqsk's IPv6 remote address was not initialised then.
    
    However, SELinux/Smack started to read it in netlbl_req_setattr()
    after commit e1adea927080 ("calipso: Allow request sockets to be
    relabelled by the lsm.").
    
    Commit 284904aa7946 ("lsm: Relocate the IPv4 security_inet_conn_request()
    hooks") fixed that kind of issue only in TCPv4 because IPv6 labeling was
    not supported at that time.  Finally, the same issue was introduced again
    in IPv6.
    
    Let's apply the same fix on DCCPv6 and TCPv6.
    
    Fixes: e1adea927080 ("calipso: Allow request sockets to be relabelled by the lsm.")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dccp: Call security_inet_conn_request() after setting IPv4 addresses. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Mon Oct 30 13:10:41 2023 -0700

    dccp: Call security_inet_conn_request() after setting IPv4 addresses.
    
    [ Upstream commit fa2df45af13091f76b89adb84a28f13818d5d631 ]
    
    Initially, commit 4237c75c0a35 ("[MLSXFRM]: Auto-labeling of child
    sockets") introduced security_inet_conn_request() in some functions
    where reqsk is allocated.  The hook is added just after the allocation,
    so reqsk's IPv4 remote address was not initialised then.
    
    However, SELinux/Smack started to read it in netlbl_req_setattr()
    after the cited commits.
    
    This bug was partially fixed by commit 284904aa7946 ("lsm: Relocate
    the IPv4 security_inet_conn_request() hooks").
    
    This patch fixes the last bug in DCCPv4.
    
    Fixes: 389fb800ac8b ("netlabel: Label incoming TCP connections correctly in SELinux")
    Fixes: 07feee8f812f ("netlabel: Cleanup the Smack/NetLabel code to fix incoming TCP connections")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Acked-by: Paul Moore <paul@paul-moore.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: pxa_dma: Remove an erroneous BUG_ON() in pxad_free_desc() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Oct 7 13:13:09 2023 +0200

    dmaengine: pxa_dma: Remove an erroneous BUG_ON() in pxad_free_desc()
    
    [ Upstream commit 83c761f568733277ce1f7eb9dc9e890649c29a8c ]
    
    If pxad_alloc_desc() fails on the first dma_pool_alloc() call, then
    sw_desc->nb_desc is zero.
    In such a case pxad_free_desc() is called and it will BUG_ON().
    
    Remove this erroneous BUG_ON().
    
    It is also useless, because if "sw_desc->nb_desc == 0", then, on the first
    iteration of the for loop, i is -1 and the loop will not be executed.
    (both i and sw_desc->nb_desc are 'int')
    
    Fixes: a57e16cf0333 ("dmaengine: pxa: add pxa dmaengine driver")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/c8fc5563c9593c914fde41f0f7d1489a21b45a9a.1696676782.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

dmaengine: ti: edma: handle irq_of_parse_and_map() errors [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Fri Sep 15 15:59:59 2023 +0300

    dmaengine: ti: edma: handle irq_of_parse_and_map() errors
    
    [ Upstream commit 14f6d317913f634920a640e9047aa2e66f5bdcb7 ]
    
    Zero is not a valid IRQ for in-kernel code and the irq_of_parse_and_map()
    function returns zero on error.  So this check for valid IRQs should only
    accept values > 0.
    
    Fixes: 2b6b3b742019 ("ARM/dmaengine: edma: Merge the two drivers under drivers/dma/")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
    Link: https://lore.kernel.org/r/f15cb6a7-8449-4f79-98b6-34072f04edbc@moroto.mountain
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/radeon: possible buffer overflow [+ + +]
Author: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Date:   Thu Aug 17 19:33:49 2023 +0800

    drm/radeon: possible buffer overflow
    
    [ Upstream commit dd05484f99d16715a88eedfca363828ef9a4c2d4 ]
    
    Buffer 'afmt_status' of size 6 could overflow, since index 'afmt_idx' is
    checked after access.
    
    Fixes: 5cc4e5fc293b ("drm/radeon: Cleanup HDMI audio interrupt handling for evergreen")
    Co-developed-by: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
    Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/rockchip: cdn-dp: Fix some error handling paths in cdn_dp_probe() [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Sep 2 19:34:31 2023 +0200

    drm/rockchip: cdn-dp: Fix some error handling paths in cdn_dp_probe()
    
    [ Upstream commit 44b968d0d0868b7a9b7a5c64464ada464ff4d532 ]
    
    cdn_dp_audio_codec_init() can fail. So add some error handling.
    
    If component_add() fails, the previous cdn_dp_audio_codec_init() call
    should be undone, as already done in the remove function.
    
    Fixes: 88582f564692 ("drm/rockchip: cdn-dp: Don't unregister audio dev when unbinding")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/8494a41602fadb7439630921a9779640698f2f9f.1693676045.git.christophe.jaillet@wanadoo.fr
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/rockchip: vop: Fix reset of state in duplicate state crtc funcs [+ + +]
Author: Jonas Karlman <jonas@kwiboo.se>
Date:   Wed Jun 21 22:33:17 2023 +0000

    drm/rockchip: vop: Fix reset of state in duplicate state crtc funcs
    
    [ Upstream commit 13fc28804bf10ca0b7bce3efbba95c534836d7ca ]
    
    struct rockchip_crtc_state members such as output_type, output_bpc and
    enable_afbc is always reset to zero in the atomic_duplicate_state crtc
    funcs.
    
    Fix this by using kmemdup on the subclass rockchip_crtc_state struct.
    
    Fixes: 4e257d9eee23 ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
    Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
    Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20230621223311.2239547-2-jonas@kwiboo.se
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ext4: move 'ix' sanity check to corrent position [+ + +]
Author: Gou Hao <gouhao@uniontech.com>
Date:   Wed Sep 6 09:33:41 2023 +0800

    ext4: move 'ix' sanity check to corrent position
    
    [ Upstream commit af90a8f4a09ec4a3de20142e37f37205d4687f28 ]
    
    Check 'ix' before it is used.
    
    Fixes: 80e675f906db ("ext4: optimize memmmove lengths in extent/index insertions")
    Signed-off-by: Gou Hao <gouhao@uniontech.com>
    Link: https://lore.kernel.org/r/20230906013341.7199-1-gouhao@uniontech.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbdev: fsl-diu-fb: mark wr_reg_wa() static [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Nov 8 13:58:42 2023 +0100

    fbdev: fsl-diu-fb: mark wr_reg_wa() static
    
    [ Upstream commit a5035c81847430dfa3482807b07325f29e9e8c09 ]
    
    wr_reg_wa() is not an appropriate name for a global function, and doesn't need
    to be global anyway, so mark it static and avoid the warning:
    
    drivers/video/fbdev/fsl-diu-fb.c:493:6: error: no previous prototype for 'wr_reg_wa' [-Werror=missing-prototypes]
    
    Fixes: 0d9dab39fbbe ("powerpc/5121: fsl-diu-fb: fix issue with re-enabling DIU area descriptor")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
firmware: ti_sci: Mark driver as non removable [+ + +]
Author: Dhruva Gole <d-gole@ti.com>
Date:   Thu Sep 21 14:40:26 2023 +0530

    firmware: ti_sci: Mark driver as non removable
    
    [ Upstream commit 7b7a224b1ba1703583b25a3641ad9798f34d832a ]
    
    The TI-SCI message protocol provides a way to communicate between
    various compute processors with a central system controller entity. It
    provides the fundamental device management capability and clock control
    in the SOCs that it's used in.
    
    The remove function failed to do all the necessary cleanup if
    there are registered users. Some things are freed however which
    likely results in an oops later on.
    
    Ensure that the driver isn't unbound by suppressing its bind and unbind
    sysfs attributes. As the driver is built-in there is no way to remove
    device once bound.
    
    We can also remove the ti_sci_remove call along with the
    ti_sci_debugfs_destroy as there are no callers for it any longer.
    
    Fixes: aa276781a64a ("firmware: Add basic support for TI System Control Interface (TI-SCI) protocol")
    Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Closes: https://lore.kernel.org/linux-arm-kernel/20230216083908.mvmydic5lpi3ogo7@pengutronix.de/
    Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Dhruva Gole <d-gole@ti.com>
    Link: https://lore.kernel.org/r/20230921091025.133130-1-d-gole@ti.com
    Signed-off-by: Nishanth Menon <nm@ti.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hwrng: geode - fix accessing registers [+ + +]
Author: Jonas Gorski <jonas.gorski@gmail.com>
Date:   Sun Sep 10 10:34:17 2023 +0200

    hwrng: geode - fix accessing registers
    
    [ Upstream commit 464bd8ec2f06707f3773676a1bd2c64832a3c805 ]
    
    When the membase and pci_dev pointer were moved to a new struct in priv,
    the actual membase users were left untouched, and they started reading
    out arbitrary memory behind the struct instead of registers. This
    unfortunately turned the RNG into a constant number generator, depending
    on the content of what was at that offset.
    
    To fix this, update geode_rng_data_{read,present}() to also get the
    membase via amd_geode_priv, and properly read from the right addresses
    again.
    
    Fixes: 9f6ec8dc574e ("hwrng: geode - Fix PCI device refcount leak")
    Reported-by: Timur I. Davletshin <timur.davletshin@gmail.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217882
    Tested-by: Timur I. Davletshin <timur.davletshin@gmail.com>
    Suggested-by: Jo-Philipp Wich <jo@mein.io>
    Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: fix potential memory leaks in i40e_remove() [+ + +]
Author: Andrii Staikov <andrii.staikov@intel.com>
Date:   Fri Sep 8 14:42:01 2023 +0200

    i40e: fix potential memory leaks in i40e_remove()
    
    [ Upstream commit 5ca636d927a106780451d957734f02589b972e2b ]
    
    Instead of freeing memory of a single VSI, make sure
    the memory for all VSIs is cleared before releasing VSIs.
    Add releasing of their resources in a loop with the iteration
    number equal to the number of allocated VSIs.
    
    Fixes: 41c445ff0f48 ("i40e: main driver core")
    Signed-off-by: Andrii Staikov <andrii.staikov@intel.com>
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
 
ipv6: avoid atomic fragment on GSO packets [+ + +]
Author: Yan Zhai <yan@cloudflare.com>
Date:   Tue Oct 24 07:26:40 2023 -0700

    ipv6: avoid atomic fragment on GSO packets
    
    [ Upstream commit 03d6c848bfb406e9ef6d9846d759e97beaeea113 ]
    
    When the ipv6 stack output a GSO packet, if its gso_size is larger than
    dst MTU, then all segments would be fragmented. However, it is possible
    for a GSO packet to have a trailing segment with smaller actual size
    than both gso_size as well as the MTU, which leads to an "atomic
    fragment". Atomic fragments are considered harmful in RFC-8021. An
    Existing report from APNIC also shows that atomic fragments are more
    likely to be dropped even it is equivalent to a no-op [1].
    
    Add an extra check in the GSO slow output path. For each segment from
    the original over-sized packet, if it fits with the path MTU, then avoid
    generating an atomic fragment.
    
    Link: https://www.potaroo.net/presentations/2022-03-01-ipv6-frag.pdf [1]
    Fixes: b210de4f8c97 ("net: ipv6: Validate GSO SKB before finish IPv6 processing")
    Reported-by: David Wragg <dwragg@cloudflare.com>
    Signed-off-by: Yan Zhai <yan@cloudflare.com>
    Link: https://lore.kernel.org/r/90912e3503a242dca0bc36958b11ed03a2696e5e.1698156966.git.yan@cloudflare.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 4.14.330 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Nov 20 10:27:36 2023 +0100

    Linux 4.14.330
    
    Link: https://lore.kernel.org/r/20231115191419.641552204@linuxfoundation.org
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
llc: verify mac len before reading mac header [+ + +]
Author: Willem de Bruijn <willemb@google.com>
Date:   Wed Oct 25 19:42:38 2023 -0400

    llc: verify mac len before reading mac header
    
    [ Upstream commit 7b3ba18703a63f6fd487183b9262b08e5632da1b ]
    
    LLC reads the mac header with eth_hdr without verifying that the skb
    has an Ethernet header.
    
    Syzbot was able to enter llc_rcv on a tun device. Tun can insert
    packets without mac len and with user configurable skb->protocol
    (passing a tun_pi header when not configuring IFF_NO_PI).
    
        BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
        BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
        llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
        llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
        llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
        __netif_receive_skb_one_core net/core/dev.c:5523 [inline]
        __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
        netif_receive_skb_internal net/core/dev.c:5723 [inline]
        netif_receive_skb+0x58/0x660 net/core/dev.c:5782
        tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
        tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002
    
    Add a mac_len test before all three eth_hdr(skb) calls under net/llc.
    
    There are further uses in include/net/llc_pdu.h. All these are
    protected by a test skb->protocol == ETH_P_802_2. Which does not
    protect against this tun scenario.
    
    But the mac_len test added in this patch in llc_fixup_skb will
    indirectly protect those too. That is called from llc_rcv before any
    other LLC code.
    
    It is tempting to just add a blanket mac_len check in llc_rcv, but
    not sure whether that could break valid LLC paths that do not assume
    an Ethernet header. 802.2 LLC may be used on top of non-802.3
    protocols in principle. The below referenced commit shows that used
    to, on top of Token Ring.
    
    At least one of the three eth_hdr uses goes back to before the start
    of git history. But the one that syzbot exercises is introduced in
    this commit. That commit is old enough (2008), that effectively all
    stable kernels should receive this.
    
    Fixes: f83f1768f833 ("[LLC]: skb allocation size for responses")
    Reported-by: syzbot+a8c7be6dee0de1b669cc@syzkaller.appspotmail.com
    Signed-off-by: Willem de Bruijn <willemb@google.com>
    Link: https://lore.kernel.org/r/20231025234251.3796495-1-willemdebruijn.kernel@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
media: dvb-usb-v2: af9035: fix missing unlock [+ + +]
Author: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Date:   Fri Oct 6 12:08:45 2023 +0200

    media: dvb-usb-v2: af9035: fix missing unlock
    
    [ Upstream commit f31b2cb85f0ee165d78e1c43f6d69f82cc3b2145 ]
    
    Instead of returning an error, goto the mutex unlock at
    the end of the function.
    
    Fixes smatch warning:
    
    drivers/media/usb/dvb-usb-v2/af9035.c:467 af9035_i2c_master_xfer() warn: inconsistent returns '&d->i2c_mutex'.
      Locked on  : 326,387
      Unlocked on: 465,467
    
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Fixes: 7bf744f2de0a ("media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer")
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: s3c-camif: Avoid inappropriate kfree() [+ + +]
Author: Katya Orlova <e.orlova@ispras.ru>
Date:   Fri Sep 22 14:55:06 2023 +0300

    media: s3c-camif: Avoid inappropriate kfree()
    
    [ Upstream commit 61334819aca018c3416ee6c330a08a49c1524fc3 ]
    
    s3c_camif_register_video_node() works with video_device structure stored
    as a field of camif_vp, so it should not be kfreed.
    But there is video_device_release() on error path that do it.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Fixes: babde1c243b2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface")
    Signed-off-by: Katya Orlova <e.orlova@ispras.ru>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mfd: dln2: Fix double put in dln2_probe [+ + +]
Author: Dinghao Liu <dinghao.liu@zju.edu.cn>
Date:   Mon Sep 25 10:41:33 2023 +0800

    mfd: dln2: Fix double put in dln2_probe
    
    [ Upstream commit 759c409bc5fc496cbc22cd0b392d3cbb0c0e23eb ]
    
    The dln2_free() already contains usb_put_dev(). Therefore,
    the redundant usb_put_dev() before dln2_free() may lead to
    a double free.
    
    Fixes: 96da8f148396 ("mfd: dln2: Fix memory leak in dln2_probe()")
    Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
    Link: https://lore.kernel.org/r/20230925024134.9683-1-dinghao.liu@zju.edu.cn
    Signed-off-by: Lee Jones <lee@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
misc: st_core: Do not call kfree_skb() under spin_lock_irqsave() [+ + +]
Author: Jinjie Ruan <ruanjinjie@huawei.com>
Date:   Wed Aug 23 11:50:20 2023 +0800

    misc: st_core: Do not call kfree_skb() under spin_lock_irqsave()
    
    [ Upstream commit 4d08c3d12b61022501989f9f071514d2d6f77c47 ]
    
    It is not allowed to call kfree_skb() from hardware interrupt
    context or with hardware interrupts being disabled.
    So replace kfree_skb() with dev_kfree_skb_irq() under
    spin_lock_irqsave(). Compile tested only.
    
    Fixes: 53618cc1e51e ("Staging: sources for ST core")
    Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
    Link: https://lore.kernel.org/r/20230823035020.1281892-1-ruanjinjie@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
netfilter: xt_recent: fix (increase) ipv6 literal buffer length [+ + +]
Author: Maciej Żenczykowski <zenczykowski@gmail.com>
Date:   Sun Nov 5 11:56:00 2023 -0800

    netfilter: xt_recent: fix (increase) ipv6 literal buffer length
    
    [ Upstream commit 7b308feb4fd2d1c06919445c65c8fbf8e9fd1781 ]
    
    in6_pton() supports 'low-32-bit dot-decimal representation'
    (this is useful with DNS64/NAT64 networks for example):
    
      # echo +aaaa:bbbb:cccc:dddd:eeee:ffff:1.2.3.4 > /proc/self/net/xt_recent/DEFAULT
      # cat /proc/self/net/xt_recent/DEFAULT
      src=aaaa:bbbb:cccc:dddd:eeee:ffff:0102:0304 ttl: 0 last_seen: 9733848829 oldest_pkt: 1 9733848829
    
    but the provided buffer is too short:
    
      # echo +aaaa:bbbb:cccc:dddd:eeee:ffff:255.255.255.255 > /proc/self/net/xt_recent/DEFAULT
      -bash: echo: write error: Invalid argument
    
    Fixes: 079aa88fe717 ("netfilter: xt_recent: IPv6 support")
    Signed-off-by: Maciej Żenczykowski <zenczykowski@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pcmcia: cs: fix possible hung task and memory leak pccardd() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Sat Nov 12 17:25:41 2022 +0800

    pcmcia: cs: fix possible hung task and memory leak pccardd()
    
    [ Upstream commit e3ea1b4847e49234e691c0d66bf030bd65bb7f2b ]
    
    If device_register() returns error in pccardd(), it leads two issues:
    
    1. The socket_released has never been completed, it will block
       pcmcia_unregister_socket(), because of waiting for completion
       of socket_released.
    2. The device name allocated by dev_set_name() is leaked.
    
    Fix this two issues by calling put_device() when device_register() fails.
    socket_released can be completed in pcmcia_release_socket(), the name can
    be freed in kobject_cleanup().
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pcmcia: ds: fix possible name leak in error path in pcmcia_device_add() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Sat Nov 12 17:29:24 2022 +0800

    pcmcia: ds: fix possible name leak in error path in pcmcia_device_add()
    
    [ Upstream commit 99e1241049a92dd3e9a90a0f91e32ce390133278 ]
    
    Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's
    bus_id string array"), the name of device is allocated dynamically.
    Therefore, it needs to be freed, which is done by the driver core for
    us once all references to the device are gone. Therefore, move the
    dev_set_name() call immediately before the call device_register(), which
    either succeeds (then the freeing will be done upon subsequent remvoal),
    or puts the reference in the error call. Also, it is not unusual that the
    return value of dev_set_name is not checked.
    
    Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    [linux@dominikbrodowski.net: simplification, commit message modified]
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

pcmcia: ds: fix refcount leak in pcmcia_device_add() [+ + +]
Author: Yang Yingliang <yangyingliang@huawei.com>
Date:   Sat Nov 12 17:29:23 2022 +0800

    pcmcia: ds: fix refcount leak in pcmcia_device_add()
    
    [ Upstream commit 402ab979b29126068e0b596b641422ff7490214c ]
    
    As the comment of device_register() says, it should use put_device()
    to give up the reference in the error path. Then, insofar resources
    will be freed in pcmcia_release_dev(), the error path is no longer
    needed. In particular, this means that the (previously missing) dropping
    of the reference to &p_dev->function_config->ref is now handled by
    pcmcia_release_dev().
    
    Fixes: 360b65b95bae ("[PATCH] pcmcia: make config_t independent, add reference counting")
    Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
    [linux@dominikbrodowski.net: simplification, commit message rewrite]
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: wmi: Fix probe failure when failing to register WMI devices [+ + +]
Author: Armin Wolf <W_Armin@gmx.de>
Date:   Fri Oct 20 23:10:03 2023 +0200

    platform/x86: wmi: Fix probe failure when failing to register WMI devices
    
    [ Upstream commit ed85891a276edaf7a867de0e9acd0837bc3008f2 ]
    
    When a WMI device besides the first one somehow fails to register,
    retval is returned while still containing a negative error code. This
    causes the ACPI device fail to probe, leaving behind zombie WMI devices
    leading to various errors later.
    
    Handle the single error path separately and return 0 unconditionally
    after trying to register all WMI devices to solve the issue. Also
    continue to register WMI devices even if some fail to allocate memory.
    
    Fixes: 6ee50aaa9a20 ("platform/x86: wmi: Instantiate all devices before adding them")
    Signed-off-by: Armin Wolf <W_Armin@gmx.de>
    Link: https://lore.kernel.org/r/20231020211005.38216-4-W_Armin@gmx.de
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pwm: brcmstb: Utilize appropriate clock APIs in suspend/resume [+ + +]
Author: Florian Fainelli <florian.fainelli@broadcom.com>
Date:   Wed Oct 4 10:54:14 2023 -0700

    pwm: brcmstb: Utilize appropriate clock APIs in suspend/resume
    
    [ Upstream commit e9bc4411548aaa738905d37851a0146c16b3bb21 ]
    
    The suspend/resume functions currently utilize
    clk_disable()/clk_enable() respectively which may be no-ops with certain
    clock providers such as SCMI. Fix this to use clk_disable_unprepare()
    and clk_prepare_enable() respectively as we should.
    
    Fixes: 3a9f5957020f ("pwm: Add Broadcom BCM7038 PWM controller support")
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
RDMA/hfi1: Workaround truncation compilation error [+ + +]
Author: Leon Romanovsky <leon@kernel.org>
Date:   Tue Oct 24 18:07:31 2023 +0300

    RDMA/hfi1: Workaround truncation compilation error
    
    [ Upstream commit d4b2d165714c0ce8777d5131f6e0aad617b7adc4 ]
    
    Increase name array to be large enough to overcome the following
    compilation error.
    
    drivers/infiniband/hw/hfi1/efivar.c: In function ‘read_hfi1_efi_var’:
    drivers/infiniband/hw/hfi1/efivar.c:124:44: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
      124 |         snprintf(name, sizeof(name), "%s-%s", prefix_name, kind);
          |                                            ^
    drivers/infiniband/hw/hfi1/efivar.c:124:9: note: ‘snprintf’ output 2 or more bytes (assuming 65) into a destination of size 64
      124 |         snprintf(name, sizeof(name), "%s-%s", prefix_name, kind);
          |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    drivers/infiniband/hw/hfi1/efivar.c:133:52: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=]
      133 |                 snprintf(name, sizeof(name), "%s-%s", prefix_name, kind);
          |                                                    ^
    drivers/infiniband/hw/hfi1/efivar.c:133:17: note: ‘snprintf’ output 2 or more bytes (assuming 65) into a destination of size 64
      133 |                 snprintf(name, sizeof(name), "%s-%s", prefix_name, kind);
          |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    cc1: all warnings being treated as errors
    make[6]: *** [scripts/Makefile.build:243: drivers/infiniband/hw/hfi1/efivar.o] Error 1
    
    Fixes: c03c08d50b3d ("IB/hfi1: Check upper-case EFI variables")
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Link: https://lore.kernel.org/r/238fa39a8fd60e87a5ad7e1ca6584fcdf32e9519.1698159993.git.leonro@nvidia.com
    Acked-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "mmc: core: Capture correct oemid-bits for eMMC cards" [+ + +]
Author: Dominique Martinet <dominique.martinet@atmark-techno.com>
Date:   Fri Nov 3 09:42:20 2023 +0900

    Revert "mmc: core: Capture correct oemid-bits for eMMC cards"
    
    commit 421b605edb1ce611dee06cf6fd9a1c1f2fd85ad0 upstream.
    
    This reverts commit 84ee19bffc9306128cd0f1c650e89767079efeff.
    
    The commit above made quirks with an OEMID fail to be applied, as they
    were checking card->cid.oemid for the full 16 bits defined in MMC_FIXUP
    macros but the field would only contain the bottom 8 bits.
    
    eMMC v5.1A might have bogus values in OEMID's higher bits so another fix
    will be made, but it has been decided to revert this until that is ready.
    
    Fixes: 84ee19bffc93 ("mmc: core: Capture correct oemid-bits for eMMC cards")
    Link: https://lkml.kernel.org/r/ZToJsSLHr8RnuTHz@codewreck.org
    Link: https://lkml.kernel.org/r/CAPDyKFqkKibcXnwjnhc3+W1iJBHLeqQ9BpcZrSwhW2u9K2oUtg@mail.gmail.com
    Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
    Cc: stable@vger.kernel.org
    Cc: Alex Fetters <Alex.Fetters@garmin.com>
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Link: https://lore.kernel.org/r/20231103004220.1666641-1-asmadeus@codewreck.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
sh: bios: Revive earlyprintk support [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Oct 19 11:46:43 2023 +0200

    sh: bios: Revive earlyprintk support
    
    [ Upstream commit 553f7ac78fbb41b2c93ab9b9d78e42274d27daa9 ]
    
    The SuperH BIOS earlyprintk code is protected by CONFIG_EARLY_PRINTK.
    However, when this protection was added, it was missed that SuperH no
    longer defines an EARLY_PRINTK config symbol since commit
    e76fe57447e88916 ("sh: Remove old early serial console code V2"), so
    BIOS earlyprintk can no longer be used.
    
    Fix this by reviving the EARLY_PRINTK config symbol.
    
    Fixes: d0380e6c3c0f6edb ("early_printk: consolidate random copies of identical code")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Link: https://lore.kernel.org/r/c40972dfec3dcc6719808d5df388857360262878.1697708489.git.geert+renesas@glider.be
    Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp_metrics: do not create an entry from tcp_init_metrics() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Sep 22 22:03:55 2023 +0000

    tcp_metrics: do not create an entry from tcp_init_metrics()
    
    [ Upstream commit a135798e6e200ecb2f864cecca6d257ba278370c ]
    
    tcp_init_metrics() only wants to get metrics if they were
    previously stored in the cache. Creating an entry is adding
    useless costs, especially when tcp_no_metrics_save is set.
    
    Fixes: 51c5d0c4b169 ("tcp: Maintain dynamic metrics in local cache.")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

tcp_metrics: properly set tp->snd_ssthresh in tcp_init_metrics() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Sep 22 22:03:54 2023 +0000

    tcp_metrics: properly set tp->snd_ssthresh in tcp_init_metrics()
    
    [ Upstream commit 081480014a64a69d901f8ef1ffdd56d6085cf87e ]
    
    We need to set tp->snd_ssthresh to TCP_INFINITE_SSTHRESH
    in the case tcp_get_metrics() fails for some reason.
    
    Fixes: 9ad7c049f0f7 ("tcp: RFC2988bis + taking RTT sample from 3WHS for the passive open side")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Acked-by: Neal Cardwell <ncardwell@google.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tg3: power down device only on SYSTEM_POWER_OFF [+ + +]
Author: George Shuklin <george.shuklin@gmail.com>
Date:   Fri Nov 3 13:50:29 2023 +0200

    tg3: power down device only on SYSTEM_POWER_OFF
    
    [ Upstream commit 9fc3bc7643341dc5be7d269f3d3dbe441d8d7ac3 ]
    
    Dell R650xs servers hangs on reboot if tg3 driver calls
    tg3_power_down.
    
    This happens only if network adapters (BCM5720 for R650xs) were
    initialized using SNP (e.g. by booting ipxe.efi).
    
    The actual problem is on Dell side, but this fix allows servers
    to come back alive after reboot.
    
    Signed-off-by: George Shuklin <george.shuklin@gmail.com>
    Fixes: 2ca1c94ce0b6 ("tg3: Disable tg3 device on system reboot to avoid triggering AER")
    Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
    Reviewed-by: Michael Chan <michael.chan@broadcom.com>
    Link: https://lore.kernel.org/r/20231103115029.83273-1-george.shuklin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
thermal: core: prevent potential string overflow [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Sat Oct 7 11:59:39 2023 +0300

    thermal: core: prevent potential string overflow
    
    [ Upstream commit c99626092efca3061b387043d4a7399bf75fbdd5 ]
    
    The dev->id value comes from ida_alloc() so it's a number between zero
    and INT_MAX.  If it's too high then these sprintf()s will overflow.
    
    Fixes: 203d3d4aa482 ("the generic thermal sysfs driver")
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING [+ + +]
Author: Shigeru Yoshida <syoshida@redhat.com>
Date:   Mon Oct 30 16:55:40 2023 +0900

    tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
    
    [ Upstream commit 19b3f72a41a8751e26bffc093bb7e1cef29ad579 ]
    
    syzbot reported the following uninit-value access issue [1]:
    
    =====================================================
    BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
    BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
     strlen lib/string.c:418 [inline]
     strstr+0xb8/0x2f0 lib/string.c:756
     tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
     genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
     genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
     genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
     netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
     genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
     netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
     netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
     netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
     sock_sendmsg_nosec net/socket.c:730 [inline]
     sock_sendmsg net/socket.c:753 [inline]
     ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
     ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
     __sys_sendmsg net/socket.c:2624 [inline]
     __do_sys_sendmsg net/socket.c:2633 [inline]
     __se_sys_sendmsg net/socket.c:2631 [inline]
     __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    Uninit was created at:
     slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
     slab_alloc_node mm/slub.c:3478 [inline]
     kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
     kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
     __alloc_skb+0x318/0x740 net/core/skbuff.c:650
     alloc_skb include/linux/skbuff.h:1286 [inline]
     netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]
     netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885
     sock_sendmsg_nosec net/socket.c:730 [inline]
     sock_sendmsg net/socket.c:753 [inline]
     ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
     ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
     __sys_sendmsg net/socket.c:2624 [inline]
     __do_sys_sendmsg net/socket.c:2633 [inline]
     __se_sys_sendmsg net/socket.c:2631 [inline]
     __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
     do_syscall_x64 arch/x86/entry/common.c:50 [inline]
     do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
     entry_SYSCALL_64_after_hwframe+0x63/0xcd
    
    TIPC bearer-related names including link names must be null-terminated
    strings. If a link name which is not null-terminated is passed through
    netlink, strstr() and similar functions can cause buffer overrun. This
    causes the above issue.
    
    This patch changes the nla_policy for bearer-related names from NLA_STRING
    to NLA_NUL_STRING. This resolves the issue by ensuring that only
    null-terminated strings are accepted as bearer-related names.
    
    syzbot reported similar uninit-value issue related to bearer names [2]. The
    root cause of this issue is that a non-null-terminated bearer name was
    passed. This patch also resolved this issue.
    
    Fixes: 7be57fc69184 ("tipc: add link get/dump to new netlink api")
    Fixes: 0655f6a8635b ("tipc: add bearer disable/enable to new netlink api")
    Reported-and-tested-by: syzbot+5138ca807af9d2b42574@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=5138ca807af9d2b42574 [1]
    Reported-and-tested-by: syzbot+9425c47dccbcb4c17d51@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=9425c47dccbcb4c17d51 [2]
    Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Link: https://lore.kernel.org/r/20231030075540.3784537-1-syoshida@redhat.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tty: tty_jobctrl: fix pid memleak in disassociate_ctty() [+ + +]
Author: Yi Yang <yiyang13@huawei.com>
Date:   Thu Aug 31 10:33:29 2023 +0800

    tty: tty_jobctrl: fix pid memleak in disassociate_ctty()
    
    [ Upstream commit 11e7f27b79757b6586645d87b95d5b78375ecdfc ]
    
    There is a pid leakage:
    ------------------------------
    unreferenced object 0xffff88810c181940 (size 224):
      comm "sshd", pid 8191, jiffies 4294946950 (age 524.570s)
      hex dump (first 32 bytes):
        01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de  .............N..
        ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff  ....kkkk........
      backtrace:
        [<ffffffff814774e6>] kmem_cache_alloc+0x5c6/0x9b0
        [<ffffffff81177342>] alloc_pid+0x72/0x570
        [<ffffffff81140ac4>] copy_process+0x1374/0x2470
        [<ffffffff81141d77>] kernel_clone+0xb7/0x900
        [<ffffffff81142645>] __se_sys_clone+0x85/0xb0
        [<ffffffff8114269b>] __x64_sys_clone+0x2b/0x30
        [<ffffffff83965a72>] do_syscall_64+0x32/0x80
        [<ffffffff83a00085>] entry_SYSCALL_64_after_hwframe+0x61/0xc6
    
    It turns out that there is a race condition between disassociate_ctty() and
    tty_signal_session_leader(), which caused this leakage.
    
    The pid memleak is triggered by the following race:
    task[sshd]                     task[bash]
    -----------------------        -----------------------
                                   disassociate_ctty();
                                   spin_lock_irq(¤t->sighand->siglock);
                                   put_pid(current->signal->tty_old_pgrp);
                                   current->signal->tty_old_pgrp = NULL;
                                   tty = tty_kref_get(current->signal->tty);
                                   spin_unlock_irq(¤t->sighand->siglock);
    tty_vhangup();
    tty_lock(tty);
    ...
    tty_signal_session_leader();
    spin_lock_irq(&p->sighand->siglock);
    ...
    if (tty->ctrl.pgrp) //tty->ctrl.pgrp is not NULL
    p->signal->tty_old_pgrp = get_pid(tty->ctrl.pgrp); //An extra get
    spin_unlock_irq(&p->sighand->siglock);
    ...
    tty_unlock(tty);
                                   if (tty) {
                                       tty_lock(tty);
                                       ...
                                       put_pid(tty->ctrl.pgrp);
                                       tty->ctrl.pgrp = NULL; //It's too late
                                       ...
                                       tty_unlock(tty);
                                   }
    
    The issue is believed to be introduced by commit c8bcd9c5be24 ("tty:
    Fix ->session locking") who moves the unlock of siglock in
    disassociate_ctty() above "if (tty)", making a small window allowing
    tty_signal_session_leader() to kick in. It can be easily reproduced by
    adding a delay before "if (tty)" and at the entrance of
    tty_signal_session_leader().
    
    To fix this issue, we move "put_pid(current->signal->tty_old_pgrp)" after
    "tty->ctrl.pgrp = NULL".
    
    Fixes: c8bcd9c5be24 ("tty: Fix ->session locking")
    Signed-off-by: Yi Yang <yiyang13@huawei.com>
    Co-developed-by: GUO Zihua <guozihua@huawei.com>
    Signed-off-by: GUO Zihua <guozihua@huawei.com>
    Link: https://lore.kernel.org/r/20230831023329.165737-1-yiyang13@huawei.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency [+ + +]
Author: Jia-Ju Bai <baijiaju@buaa.edu.cn>
Date:   Tue Sep 26 10:44:04 2023 +0800

    usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency
    
    [ Upstream commit ef307bc6ef04e8c1ea843231db58e3afaafa9fa6 ]
    
    In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without
    holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue():
    
        spin_lock_irqsave(&hsotg->lock, flags);
        ...
            if (!urb->hcpriv) {
                    dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n");
                    goto out;
            }
        rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv
        ...
    out:
        spin_unlock_irqrestore(&hsotg->lock, flags);
    
    When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are
    concurrently executed, the NULL check of "urb->hcpriv" can be executed
    before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used
    in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL
    pointer dereference.
    
    This possible bug is found by an experimental static analysis tool
    developed by myself. This tool analyzes the locking APIs to extract
    function pairs that can be concurrently executed, and then analyzes the
    instructions in the paired functions to identify possible concurrency
    bugs including data races and atomicity violations. The above possible
    bug is reported, when my tool analyzes the source code of Linux 6.5.
    
    To fix this possible bug, "urb->hcpriv = NULL" should be executed with
    holding the lock "hsotg->lock". After using this patch, my tool never
    reports the possible bug, with the kernelconfiguration allyesconfig for
    x86_64. Because I have no associated hardware, I cannot test the patch
    in runtime testing, and just verify it according to the code logic.
    
    Fixes: 33ad261aa62b ("usb: dwc2: host: spinlock urb_enqueue")
    Signed-off-by: Jia-Ju Bai <baijiaju@buaa.edu.cn>
    Link: https://lore.kernel.org/r/20230926024404.832096-1-baijiaju@buaa.edu.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
USB: usbip: fix stub_dev hub disconnect [+ + +]
Author: Jonas Blixt <jonas.blixt@actia.se>
Date:   Thu Jun 15 11:28:10 2023 +0200

    USB: usbip: fix stub_dev hub disconnect
    
    [ Upstream commit 97475763484245916735a1aa9a3310a01d46b008 ]
    
    If a hub is disconnected that has device(s) that's attached to the usbip layer
    the disconnect function might fail because it tries to release the port
    on an already disconnected hub.
    
    Fixes: 6080cd0e9239 ("staging: usbip: claim ports used by shared devices")
    Signed-off-by: Jonas Blixt <jonas.blixt@actia.se>
    Acked-by: Shuah Khan <skhan@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20230615092810.1215490-1-jonas.blixt@actia.se
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: rtlwifi: fix EDCA limit set by BT coexistence [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Thu Sep 28 08:23:19 2023 +0300

    wifi: rtlwifi: fix EDCA limit set by BT coexistence
    
    [ Upstream commit 3391ee7f9ea508c375d443cd712c2e699be235b4 ]
    
    In 'rtl92c_dm_check_edca_turbo()', 'rtl88e_dm_check_edca_turbo()',
    and 'rtl8723e_dm_check_edca_turbo()', the DL limit should be set
    from the corresponding field of 'rtlpriv->btcoexist' rather than
    UL. Compile tested only.
    
    Fixes: 0529c6b81761 ("rtlwifi: rtl8723ae: Update driver to match 06/28/14 Realtek version")
    Fixes: c151aed6aa14 ("rtlwifi: rtl8188ee: Update driver to match Realtek release of 06282014")
    Fixes: beb5bc402043 ("rtlwifi: rtl8192c-common: Convert common dynamic management routines for addition of rtl8192se and rtl8192de")
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Acked-by: Ping-Ke Shih <pkshih@realtek.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://lore.kernel.org/r/20230928052327.120178-1-dmantipov@yandex.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>