Linux 5.10.215

 
ACPICA: debugger: check status of acpi_evaluate_object() in acpi_db_walk_for_fields() [+ + +]
Author: Nikita Kiryushin <kiryushin@ancud.ru>
Date:   Fri Mar 22 21:07:53 2024 +0300

    ACPICA: debugger: check status of acpi_evaluate_object() in acpi_db_walk_for_fields()
    
    [ Upstream commit 40e2710860e57411ab57a1529c5a2748abbe8a19 ]
    
    ACPICA commit 9061cd9aa131205657c811a52a9f8325a040c6c9
    
    Errors in acpi_evaluate_object() can lead to incorrect state of buffer.
    
    This can lead to access to data in previously ACPI_FREEd buffer and
    secondary ACPI_FREE to the same buffer later.
    
    Handle errors in acpi_evaluate_object the same way it is done earlier
    with acpi_ns_handle_to_pathname.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Link: https://github.com/acpica/acpica/commit/9061cd9a
    Fixes: 5fd033288a86 ("ACPICA: debugger: add command to dump all fields of particular subtype")
    Signed-off-by: Nikita Kiryushin <kiryushin@ancud.ru>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ahci: asm1064: asm1166: don't limit reported ports [+ + +]
Author: Conrad Kostecki <conikost@gentoo.org>
Date:   Wed Mar 13 22:46:50 2024 +0100

    ahci: asm1064: asm1166: don't limit reported ports
    
    [ Upstream commit 6cd8adc3e18960f6e59d797285ed34ef473cc896 ]
    
    Previously, patches have been added to limit the reported count of SATA
    ports for asm1064 and asm1166 SATA controllers, as those controllers do
    report more ports than physically having.
    
    While it is allowed to report more ports than physically having in CAP.NP,
    it is not allowed to report more ports than physically having in the PI
    (Ports Implemented) register, which is what these HBAs do.
    (This is a AHCI spec violation.)
    
    Unfortunately, it seems that the PMP implementation in these ASMedia HBAs
    is also violating the AHCI and SATA-IO PMP specification.
    
    What these HBAs do is that they do not report that they support PMP
    (CAP.SPM (Supports Port Multiplier) is not set).
    
    Instead, they have decided to add extra "virtual" ports in the PI register
    that is used if a port multiplier is connected to any of the physical
    ports of the HBA.
    
    Enumerating the devices behind the PMP as specified in the AHCI and
    SATA-IO specifications, by using PMP READ and PMP WRITE commands to the
    physical ports of the HBA is not possible, you have to use the "virtual"
    ports.
    
    This is of course bad, because this gives us no way to detect the device
    and vendor ID of the PMP actually connected to the HBA, which means that
    we can not apply the proper PMP quirks for the PMP that is connected to
    the HBA.
    
    Limiting the port map will thus stop these controllers from working with
    SATA Port Multipliers.
    
    This patch reverts both patches for asm1064 and asm1166, so old behavior
    is restored and SATA PMP will work again, but it will also reintroduce the
    (minutes long) extra boot time for the ASMedia controllers that do not
    have a PMP connected (either on the PCIe card itself, or an external PMP).
    
    However, a longer boot time for some, is the lesser evil compared to some
    other users not being able to detect their drives at all.
    
    Fixes: 0077a504e1a4 ("ahci: asm1166: correct count of reported ports")
    Fixes: 9815e3961754 ("ahci: asm1064: correct count of reported ports")
    Cc: stable@vger.kernel.org
    Reported-by: Matt <cryptearth@googlemail.com>
    Signed-off-by: Conrad Kostecki <conikost@gentoo.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    [cassel: rewrote commit message]
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ahci: asm1064: correct count of reported ports [+ + +]
Author: Andrey Jr. Melnikov <temnota.am@gmail.com>
Date:   Wed Feb 14 17:57:57 2024 +0100

    ahci: asm1064: correct count of reported ports
    
    [ Upstream commit 9815e39617541ef52d0dfac4be274ad378c6dc09 ]
    
    The ASM1064 SATA host controller always reports wrongly,
    that it has 24 ports. But in reality, it only has four ports.
    
    before:
    ahci 0000:04:00.0: SSS flag set, parallel bus scan disabled
    ahci 0000:04:00.0: AHCI 0001.0301 32 slots 24 ports 6 Gbps 0xffff0f impl SATA mode
    ahci 0000:04:00.0: flags: 64bit ncq sntf stag pm led only pio sxs deso sadm sds apst
    
    after:
    ahci 0000:04:00.0: ASM1064 has only four ports
    ahci 0000:04:00.0: forcing port_map 0xffff0f -> 0xf
    ahci 0000:04:00.0: SSS flag set, parallel bus scan disabled
    ahci 0000:04:00.0: AHCI 0001.0301 32 slots 24 ports 6 Gbps 0xf impl SATA mode
    ahci 0000:04:00.0: flags: 64bit ncq sntf stag pm led only pio sxs deso sadm sds apst
    
    Signed-off-by: "Andrey Jr. Melnikov" <temnota.am@gmail.com>
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Stable-dep-of: 6cd8adc3e189 ("ahci: asm1064: asm1166: don't limit reported ports")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ALSA: hda/realtek - Fix headset Mic no show at resume back for Lenovo ALC897 platform [+ + +]
Author: Kailang Yang <kailang@realtek.com>
Date:   Fri Mar 1 15:29:50 2024 +0800

    ALSA: hda/realtek - Fix headset Mic no show at resume back for Lenovo ALC897 platform
    
    commit d397b6e56151099cf3b1f7bfccb204a6a8591720 upstream.
    
    Headset Mic will no show at resume back.
    This patch will fix this issue.
    
    Fixes: d7f32791a9fc ("ALSA: hda/realtek - Add headset Mic support for Lenovo ALC897 platform")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Kailang Yang <kailang@realtek.com>
    Link: https://lore.kernel.org/r/4713d48a372e47f98bba0c6120fd8254@realtek.com
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: hda/realtek: Update Panasonic CF-SZ6 quirk to support headset with microphone [+ + +]
Author: I Gede Agastya Darma Laksana <gedeagas22@gmail.com>
Date:   Tue Apr 2 00:46:02 2024 +0700

    ALSA: hda/realtek: Update Panasonic CF-SZ6 quirk to support headset with microphone
    
    commit 1576f263ee2147dc395531476881058609ad3d38 upstream.
    
    This patch addresses an issue with the Panasonic CF-SZ6's existing quirk,
    specifically its headset microphone functionality. Previously, the quirk
    used ALC269_FIXUP_HEADSET_MODE, which does not support the CF-SZ6's design
    of a single 3.5mm jack for both mic and audio output effectively. The
    device uses pin 0x19 for the headset mic without jack detection.
    
    Following verification on the CF-SZ6 and discussions with the original
    patch author, i determined that the update to
    ALC269_FIXUP_ASPIRE_HEADSET_MIC is the appropriate solution. This change
    is custom-designed for the CF-SZ6's unique hardware setup, which includes
    a single 3.5mm jack for both mic and audio output, connecting the headset
    microphone to pin 0x19 without the use of jack detection.
    
    Fixes: 0fca97a29b83 ("ALSA: hda/realtek - Add Panasonic CF-SZ6 headset jack quirk")
    Signed-off-by: I Gede Agastya Darma Laksana <gedeagas22@gmail.com>
    Cc: <stable@vger.kernel.org>
    Message-ID: <20240401174602.14133-1-gedeagas22@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Tue Mar 26 17:42:38 2024 +0800

    ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs
    
    commit 051e0840ffa8ab25554d6b14b62c9ab9e4901457 upstream.
    
    The dreamcastcard->timer could schedule the spu_dma_work and the
    spu_dma_work could also arm the dreamcastcard->timer.
    
    When the snd_pcm_substream is closing, the aica_channel will be
    deallocated. But it could still be dereferenced in the worker
    thread. The reason is that del_timer() will return directly
    regardless of whether the timer handler is running or not and
    the worker could be rescheduled in the timer handler. As a result,
    the UAF bug will happen. The racy situation is shown below:
    
          (Thread 1)                 |      (Thread 2)
    snd_aicapcm_pcm_close()          |
     ...                             |  run_spu_dma() //worker
                                     |    mod_timer()
      flush_work()                   |
      del_timer()                    |  aica_period_elapsed() //timer
      kfree(dreamcastcard->channel)  |    schedule_work()
                                     |  run_spu_dma() //worker
      ...                            |    dreamcastcard->channel-> //USE
    
    In order to mitigate this bug and other possible corner cases,
    call mod_timer() conditionally in run_spu_dma(), then implement
    PCM sync_stop op to cancel both the timer and worker. The sync_stop
    op will be called from PCM core appropriately when needed.
    
    Fixes: 198de43d758c ("[ALSA] Add ALSA support for the SEGA Dreamcast PCM device")
    Suggested-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Message-ID: <20240326094238.95442-1-duoming@zju.edu.cn>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
amdkfd: use calloc instead of kzalloc to avoid integer overflow [+ + +]
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri Apr 12 06:11:25 2024 +1000

    amdkfd: use calloc instead of kzalloc to avoid integer overflow
    
    commit 3b0daecfeac0103aba8b293df07a0cbaf8b43f29 upstream.
    
    This uses calloc instead of doing the multiplication which might
    overflow.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Dave Airlie <airlied@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
arm64: dts: qcom: sc7180-trogdor: mark bluetooth address as broken [+ + +]
Author: Johan Hovold <johan+linaro@kernel.org>
Date:   Wed Mar 20 08:55:52 2024 +0100

    arm64: dts: qcom: sc7180-trogdor: mark bluetooth address as broken
    
    [ Upstream commit e12e28009e584c8f8363439f6a928ec86278a106 ]
    
    Several Qualcomm Bluetooth controllers lack persistent storage for the
    device address and instead one can be provided by the boot firmware
    using the 'local-bd-address' devicetree property.
    
    The Bluetooth bindings clearly states that the address should be
    specified in little-endian order, but due to a long-standing bug in the
    Qualcomm driver which reversed the address some boot firmware has been
    providing the address in big-endian order instead.
    
    The boot firmware in SC7180 Trogdor Chromebooks is known to be affected
    so mark the 'local-bd-address' property as broken to maintain backwards
    compatibility with older firmware when fixing the underlying driver bug.
    
    Note that ChromeOS always updates the kernel and devicetree in lockstep
    so that there is no need to handle backwards compatibility with older
    devicetrees.
    
    Fixes: 7ec3e67307f8 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt")
    Cc: stable@vger.kernel.org      # 5.10
    Cc: Rob Clark <robdclark@chromium.org>
    Reviewed-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
    Acked-by: Bjorn Andersson <andersson@kernel.org>
    Reviewed-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: qcom: sc7180: Remove clock for bluetooth on Trogdor [+ + +]
Author: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
Date:   Mon Mar 1 13:34:32 2021 -0800

    arm64: dts: qcom: sc7180: Remove clock for bluetooth on Trogdor
    
    [ Upstream commit a307a9773420dc7d385991f61fbede2fe100bd78 ]
    
    Removed voting for RPMH_RF_CLK2 which is not required as it is
    getting managed by BT SoC through SW_CTRL line.
    
    Cc: Matthias Kaehlcke <mka@chromium.org>
    Signed-off-by: Venkata Lakshmi Narayana Gubba <gubbaven@codeaurora.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
    Reviewed-by: Stephen Boyd <swboyd@chromium.org>
    Link: https://lore.kernel.org/r/20210301133318.v2.8.I80c268f163e6d49a70af1238be442b5de400c579@changeid
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Stable-dep-of: e12e28009e58 ("arm64: dts: qcom: sc7180-trogdor: mark bluetooth address as broken")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: fix rk3328 hdmi ports node [+ + +]
Author: Johan Jonker <jbx6244@gmail.com>
Date:   Wed Jan 31 22:17:08 2024 +0100

    arm64: dts: rockchip: fix rk3328 hdmi ports node
    
    [ Upstream commit 1d00ba4700d1e0f88ae70d028d2e17e39078fa1c ]
    
    Fix rk3328 hdmi ports node so that it matches the
    rockchip,dw-hdmi.yaml binding.
    
    Signed-off-by: Johan Jonker <jbx6244@gmail.com>
    Link: https://lore.kernel.org/r/e5dea3b7-bf84-4474-9530-cc2da3c41104@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

arm64: dts: rockchip: fix rk3399 hdmi ports node [+ + +]
Author: Johan Jonker <jbx6244@gmail.com>
Date:   Wed Jan 31 22:17:31 2024 +0100

    arm64: dts: rockchip: fix rk3399 hdmi ports node
    
    [ Upstream commit f051b6ace7ffcc48d6d1017191f167c0a85799f6 ]
    
    Fix rk3399 hdmi ports node so that it matches the
    rockchip,dw-hdmi.yaml binding.
    
    Signed-off-by: Johan Jonker <jbx6244@gmail.com>
    Link: https://lore.kernel.org/r/a6ab6f75-3b80-40b1-bd30-3113e14becdd@gmail.com
    Signed-off-by: Heiko Stuebner <heiko@sntech.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
arm: dts: marvell: Fix maxium->maxim typo in brownstone dts [+ + +]
Author: Duje Mihanović <duje.mihanovic@skole.hr>
Date:   Thu Jan 25 19:39:32 2024 +0100

    arm: dts: marvell: Fix maxium->maxim typo in brownstone dts
    
    [ Upstream commit 831e0cd4f9ee15a4f02ae10b67e7fdc10eb2b4fc ]
    
    Fix an obvious spelling error in the PMIC compatible in the MMP2
    Brownstone DTS file.
    
    Fixes: 58f1193e6210 ("mfd: max8925: Add dts")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
    Reported-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Closes: https://lore.kernel.org/linux-devicetree/1410884282-18041-1-git-send-email-k.kozlowski@samsung.com/
    Reviewed-by: Andrew Lunn <andrew@lunn.ch>
    Link: https://lore.kernel.org/r/20240125-brownstone-typo-fix-v2-1-45bc48a0c81c@skole.hr
    [krzysztof: Just 10 years to take a patch, not bad! Rephrased commit
     msg]
    Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: ops: Fix wraparound for mask in snd_soc_get_volsw [+ + +]
Author: Stephen Lee <slee08177@gmail.com>
Date:   Mon Mar 25 18:01:31 2024 -0700

    ASoC: ops: Fix wraparound for mask in snd_soc_get_volsw
    
    [ Upstream commit fc563aa900659a850e2ada4af26b9d7a3de6c591 ]
    
    In snd_soc_info_volsw(), mask is generated by figuring out the index of
    the most significant bit set in max and converting the index to a
    bitmask through bit shift 1. Unintended wraparound occurs when max is an
    integer value with msb bit set. Since the bit shift value 1 is treated
    as an integer type, the left shift operation will wraparound and set
    mask to 0 instead of all 1's. In order to fix this, we type cast 1 as
    `1ULL` to prevent the wraparound.
    
    Fixes: 7077148fb50a ("ASoC: core: Split ops out of soc-core.c")
    Signed-off-by: Stephen Lee <slee08177@gmail.com>
    Link: https://msgid.link/r/20240326010131.6211-1-slee08177@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ata: sata_mv: Fix PCI device ID table declaration compilation warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Apr 3 10:06:48 2024 +0200

    ata: sata_mv: Fix PCI device ID table declaration compilation warning
    
    [ Upstream commit 3137b83a90646917c90951d66489db466b4ae106 ]
    
    Building with W=1 shows a warning for an unused variable when CONFIG_PCI
    is diabled:
    
    drivers/ata/sata_mv.c:790:35: error: unused variable 'mv_pci_tbl' [-Werror,-Wunused-const-variable]
    static const struct pci_device_id mv_pci_tbl[] = {
    
    Move the table into the same block that containsn the pci_driver
    definition.
    
    Fixes: 7bb3c5290ca0 ("sata_mv: Remove PCI dependency")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ata: sata_sx4: fix pdc20621_get_from_dimm() on 64-bit [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 26 15:53:37 2024 +0100

    ata: sata_sx4: fix pdc20621_get_from_dimm() on 64-bit
    
    [ Upstream commit 52f80bb181a9a1530ade30bc18991900bbb9697f ]
    
    gcc warns about a memcpy() with overlapping pointers because of an
    incorrect size calculation:
    
    In file included from include/linux/string.h:369,
                     from drivers/ata/sata_sx4.c:66:
    In function 'memcpy_fromio',
        inlined from 'pdc20621_get_from_dimm.constprop' at drivers/ata/sata_sx4.c:962:2:
    include/linux/fortify-string.h:97:33: error: '__builtin_memcpy' accessing 4294934464 bytes at offsets 0 and [16, 16400] overlaps 6442385281 bytes at offset -2147450817 [-Werror=restrict]
       97 | #define __underlying_memcpy     __builtin_memcpy
          |                                 ^
    include/linux/fortify-string.h:620:9: note: in expansion of macro '__underlying_memcpy'
      620 |         __underlying_##op(p, q, __fortify_size);                        \
          |         ^~~~~~~~~~~~~
    include/linux/fortify-string.h:665:26: note: in expansion of macro '__fortify_memcpy_chk'
      665 | #define memcpy(p, q, s)  __fortify_memcpy_chk(p, q, s,                  \
          |                          ^~~~~~~~~~~~~~~~~~~~
    include/asm-generic/io.h:1184:9: note: in expansion of macro 'memcpy'
     1184 |         memcpy(buffer, __io_virt(addr), size);
          |         ^~~~~~
    
    The problem here is the overflow of an unsigned 32-bit number to a
    negative that gets converted into a signed 'long', keeping a large
    positive number.
    
    Replace the complex calculation with a more readable min() variant
    that avoids the warning.
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
block: add check that partition length needs to be aligned with block size [+ + +]
Author: Min Li <min15.li@samsung.com>
Date:   Thu Jun 29 14:25:17 2023 +0000

    block: add check that partition length needs to be aligned with block size
    
    commit 6f64f866aa1ae6975c95d805ed51d7e9433a0016 upstream.
    
    Before calling add partition or resize partition, there is no check
    on whether the length is aligned with the logical block size.
    If the logical block size of the disk is larger than 512 bytes,
    then the partition size maybe not the multiple of the logical block size,
    and when the last sector is read, bio_truncate() will adjust the bio size,
    resulting in an IO error if the size of the read command is smaller than
    the logical block size.If integrity data is supported, this will also
    result in a null pointer dereference when calling bio_integrity_free.
    
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Min Li <min15.li@samsung.com>
    Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20230629142517.121241-1-min15.li@samsung.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Ashwin Dayanand Kamat <ashwin.kamat@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

block: Clear zone limits for a non-zoned stacked queue [+ + +]
Author: Damien Le Moal <dlemoal@kernel.org>
Date:   Thu Feb 22 22:17:23 2024 +0900

    block: Clear zone limits for a non-zoned stacked queue
    
    [ Upstream commit c8f6f88d25929ad2f290b428efcae3b526f3eab0 ]
    
    Device mapper may create a non-zoned mapped device out of a zoned device
    (e.g., the dm-zoned target). In such case, some queue limit such as the
    max_zone_append_sectors and zone_write_granularity endup being non zero
    values for a block device that is not zoned. Avoid this by clearing
    these limits in blk_stack_limits() when the stacked zoned limit is
    false.
    
    Fixes: 3093a479727b ("block: inherit the zoned characteristics in blk_stack_limits")
    Cc: stable@vger.kernel.org
    Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
    Link: https://lore.kernel.org/r/20240222131724.1803520-1-dlemoal@kernel.org
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: introduce zone_write_granularity limit [+ + +]
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date:   Thu Jan 28 13:47:30 2021 +0900

    block: introduce zone_write_granularity limit
    
    [ Upstream commit a805a4fa4fa376bbc145762bb8b09caa2fa8af48 ]
    
    Per ZBC and ZAC specifications, host-managed SMR hard-disks mandate that
    all writes into sequential write required zones be aligned to the device
    physical block size. However, NVMe ZNS does not have this constraint and
    allows write operations into sequential zones to be aligned to the
    device logical block size. This inconsistency does not help with
    software portability across device types.
    
    To solve this, introduce the zone_write_granularity queue limit to
    indicate the alignment constraint, in bytes, of write operations into
    zones of a zoned block device. This new limit is exported as a
    read-only sysfs queue attribute and the helper
    blk_queue_zone_write_granularity() introduced for drivers to set this
    limit.
    
    The function blk_queue_set_zoned() is modified to set this new limit to
    the device logical block size by default. NVMe ZNS devices as well as
    zoned nullb devices use this default value as is. The scsi disk driver
    is modified to execute the blk_queue_zone_write_granularity() helper to
    set the zone write granularity of host-managed SMR disks to the disk
    physical block size.
    
    The accessor functions queue_zone_write_granularity() and
    bdev_zone_write_granularity() are also introduced.
    
    Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Reviewed-by: Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@edc.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Stable-dep-of: c8f6f88d2592 ("block: Clear zone limits for a non-zoned stacked queue")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

block: prevent division by zero in blk_rq_stat_sum() [+ + +]
Author: Roman Smirnov <r.smirnov@omp.ru>
Date:   Tue Mar 5 16:45:09 2024 +0300

    block: prevent division by zero in blk_rq_stat_sum()
    
    [ Upstream commit 93f52fbeaf4b676b21acfe42a5152620e6770d02 ]
    
    The expression dst->nr_samples + src->nr_samples may
    have zero value on overflow. It is necessary to add
    a check to avoid division by zero.
    
    Found by Linux Verification Center (linuxtesting.org) with Svace.
    
    Signed-off-by: Roman Smirnov <r.smirnov@omp.ru>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/20240305134509.23108-1-r.smirnov@omp.ru
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Bluetooth: btintel: Fix null ptr deref in btintel_read_version [+ + +]
Author: Edward Adam Davis <eadavis@qq.com>
Date:   Thu Jan 18 12:40:34 2024 +0800

    Bluetooth: btintel: Fix null ptr deref in btintel_read_version
    
    [ Upstream commit b79e040910101b020931ba0c9a6b77e81ab7f645 ]
    
    If hci_cmd_sync_complete() is triggered and skb is NULL, then
    hdev->req_skb is NULL, which will cause this issue.
    
    Reported-and-tested-by: syzbot+830d9e3fa61968246abd@syzkaller.appspotmail.com
    Signed-off-by: Edward Adam Davis <eadavis@qq.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Bluetooth: btintel: Fixe build regression [+ + +]
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date:   Fri Feb 23 12:36:23 2024 -0500

    Bluetooth: btintel: Fixe build regression
    
    commit 6e62ebfb49eb65bdcbfc5797db55e0ce7f79c3dd upstream.
    
    This fixes the following build regression:
    
    drivers-bluetooth-btintel.c-btintel_read_version()-warn:
    passing-zero-to-PTR_ERR
    
    Fixes: b79e04091010 ("Bluetooth: btintel: Fix null ptr deref in btintel_read_version")
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: Fix TOCTOU in HCI debugfs implementation [+ + +]
Author: Bastien Nocera <hadess@hadess.net>
Date:   Wed Mar 27 15:24:56 2024 +0100

    Bluetooth: Fix TOCTOU in HCI debugfs implementation
    
    commit 7835fcfd132eb88b87e8eb901f88436f63ab60f7 upstream.
    
    struct hci_dev members conn_info_max_age, conn_info_min_age,
    le_conn_max_interval, le_conn_min_interval, le_adv_max_interval,
    and le_adv_min_interval can be modified from the HCI core code, as well
    through debugfs.
    
    The debugfs implementation, that's only available to privileged users,
    will check for boundaries, making sure that the minimum value being set
    is strictly above the maximum value that already exists, and vice-versa.
    
    However, as both minimum and maximum values can be changed concurrently
    to us modifying them, we need to make sure that the value we check is
    the value we end up using.
    
    For example, with ->conn_info_max_age set to 10, conn_info_min_age_set()
    gets called from vfs handlers to set conn_info_min_age to 8.
    
    In conn_info_min_age_set(), this goes through:
            if (val == 0 || val > hdev->conn_info_max_age)
                    return -EINVAL;
    
    Concurrently, conn_info_max_age_set() gets called to set to set the
    conn_info_max_age to 7:
            if (val == 0 || val > hdev->conn_info_max_age)
                    return -EINVAL;
    That check will also pass because we used the old value (10) for
    conn_info_max_age.
    
    After those checks that both passed, the struct hci_dev access
    is mutex-locked, disabling concurrent access, but that does not matter
    because the invalid value checks both passed, and we'll end up with
    conn_info_min_age = 8 and conn_info_max_age = 7
    
    To fix this problem, we need to lock the structure access before so the
    check and assignment are not interrupted.
    
    This fix was originally devised by the BassCheck[1] team, and
    considered the problem to be an atomicity one. This isn't the case as
    there aren't any concerns about the variable changing while we check it,
    but rather after we check it parallel to another change.
    
    This patch fixes CVE-2024-24858 and CVE-2024-24857.
    
    [1] https://sites.google.com/view/basscheck/
    
    Co-developed-by: Gui-Dong Han <2045gemini@gmail.com>
    Signed-off-by: Gui-Dong Han <2045gemini@gmail.com>
    Link: https://lore.kernel.org/linux-bluetooth/20231222161317.6255-1-2045gemini@gmail.com/
    Link: https://nvd.nist.gov/vuln/detail/CVE-2024-24858
    Link: https://lore.kernel.org/linux-bluetooth/20231222162931.6553-1-2045gemini@gmail.com/
    Link: https://lore.kernel.org/linux-bluetooth/20231222162310.6461-1-2045gemini@gmail.com/
    Link: https://nvd.nist.gov/vuln/detail/CVE-2024-24857
    Fixes: 31ad169148df ("Bluetooth: Add conn info lifetime parameters to debugfs")
    Fixes: 729a1051da6f ("Bluetooth: Expose default LE advertising interval via debugfs")
    Fixes: 71c3b60ec6d2 ("Bluetooth: Move BR/EDR debugfs file creation into hci_debugfs.c")
    Signed-off-by: Bastien Nocera <hadess@hadess.net>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Bluetooth: hci_event: set the conn encrypted before conn establishes [+ + +]
Author: Hui Wang <hui.wang@canonical.com>
Date:   Wed Mar 27 12:30:30 2024 +0800

    Bluetooth: hci_event: set the conn encrypted before conn establishes
    
    commit c569242cd49287d53b73a94233db40097d838535 upstream.
    
    We have a BT headset (Lenovo Thinkplus XT99), the pairing and
    connecting has no problem, once this headset is paired, bluez will
    remember this device and will auto re-connect it whenever the device
    is powered on. The auto re-connecting works well with Windows and
    Android, but with Linux, it always fails. Through debugging, we found
    at the rfcomm connection stage, the bluetooth stack reports
    "Connection refused - security block (0x0003)".
    
    For this device, the re-connecting negotiation process is different
    from other BT headsets, it sends the Link_KEY_REQUEST command before
    the CONNECT_REQUEST completes, and it doesn't send ENCRYPT_CHANGE
    command during the negotiation. When the device sends the "connect
    complete" to hci, the ev->encr_mode is 1.
    
    So here in the conn_complete_evt(), if ev->encr_mode is 1, link type
    is ACL and HCI_CONN_ENCRYPT is not set, we set HCI_CONN_ENCRYPT to
    this conn, and update conn->enc_key_size accordingly.
    
    After this change, this BT headset could re-connect with Linux
    successfully. This is the btmon log after applying the patch, after
    receiving the "Connect Complete" with "Encryption: Enabled", will send
    the command to read encryption key size:
    > HCI Event: Connect Request (0x04) plen 10
            Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
            Class: 0x240404
              Major class: Audio/Video (headset, speaker, stereo, video, vcr)
              Minor class: Wearable Headset Device
              Rendering (Printing, Speaker)
              Audio (Speaker, Microphone, Headset)
            Link type: ACL (0x01)
    ...
    > HCI Event: Link Key Request (0x17) plen 6
            Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
    < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
            Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
            Link key: ${32-hex-digits-key}
    ...
    > HCI Event: Connect Complete (0x03) plen 11
            Status: Success (0x00)
            Handle: 256
            Address: 8C:3C:AA:D8:11:67 (OUI 8C-3C-AA)
            Link type: ACL (0x01)
            Encryption: Enabled (0x01)
    < HCI Command: Read Encryption Key... (0x05|0x0008) plen 2
            Handle: 256
    < ACL Data TX: Handle 256 flags 0x00 dlen 10
          L2CAP: Information Request (0x0a) ident 1 len 2
            Type: Extended features supported (0x0002)
    > HCI Event: Command Complete (0x0e) plen 7
          Read Encryption Key Size (0x05|0x0008) ncmd 1
            Status: Success (0x00)
            Handle: 256
            Key size: 16
    
    Cc: stable@vger.kernel.org
    Link: https://github.com/bluez/bluez/issues/704
    Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Reviewed-by: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
    Signed-off-by: Hui Wang <hui.wang@canonical.com>
    Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bounds: support non-power-of-two CONFIG_NR_CPUS [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Tue Oct 10 15:55:49 2023 +0100

    bounds: support non-power-of-two CONFIG_NR_CPUS
    
    [ Upstream commit f2d5dcb48f7ba9e3ff249d58fc1fa963d374e66a ]
    
    ilog2() rounds down, so for example when PowerPC 85xx sets CONFIG_NR_CPUS
    to 24, we will only allocate 4 bits to store the number of CPUs instead of
    5.  Use bits_per() instead, which rounds up.  Found by code inspection.
    The effect of this would probably be a misaccounting when doing NUMA
    balancing, so to a user, it would only be a performance penalty.  The
    effects may be more wide-spread; it's hard to tell.
    
    Link: https://lkml.kernel.org/r/20231010145549.1244748-1-willy@infradead.org
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Fixes: 90572890d202 ("mm: numa: Change page last {nid,pid} into {cpu,pid}")
    Reviewed-by: Rik van Riel <riel@surriel.com>
    Acked-by: Mel Gorman <mgorman@techsingularity.net>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
bpf, sockmap: Prevent lock inversion deadlock in map delete elem [+ + +]
Author: Jakub Sitnicki <jakub@cloudflare.com>
Date:   Tue Apr 2 12:46:21 2024 +0200

    bpf, sockmap: Prevent lock inversion deadlock in map delete elem
    
    commit ff91059932401894e6c86341915615c5eb0eca48 upstream.
    
    syzkaller started using corpuses where a BPF tracing program deletes
    elements from a sockmap/sockhash map. Because BPF tracing programs can be
    invoked from any interrupt context, locks taken during a map_delete_elem
    operation must be hardirq-safe. Otherwise a deadlock due to lock inversion
    is possible, as reported by lockdep:
    
           CPU0                    CPU1
           ----                    ----
      lock(&htab->buckets[i].lock);
                                   local_irq_disable();
                                   lock(&host->lock);
                                   lock(&htab->buckets[i].lock);
      <Interrupt>
        lock(&host->lock);
    
    Locks in sockmap are hardirq-unsafe by design. We expects elements to be
    deleted from sockmap/sockhash only in task (normal) context with interrupts
    enabled, or in softirq context.
    
    Detect when map_delete_elem operation is invoked from a context which is
    _not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an
    error.
    
    Note that map updates are not affected by this issue. BPF verifier does not
    allow updating sockmap/sockhash from a BPF tracing program today.
    
    Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
    Reported-by: xingwei lee <xrivendell7@gmail.com>
    Reported-by: yue sun <samsun1006219@gmail.com>
    Reported-by: syzbot+bc922f476bd65abbd466@syzkaller.appspotmail.com
    Reported-by: syzbot+d4066896495db380182e@syzkaller.appspotmail.com
    Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: syzbot+d4066896495db380182e@syzkaller.appspotmail.com
    Acked-by: John Fastabend <john.fastabend@gmail.com>
    Closes: https://syzkaller.appspot.com/bug?extid=d4066896495db380182e
    Closes: https://syzkaller.appspot.com/bug?extid=bc922f476bd65abbd466
    Link: https://lore.kernel.org/bpf/20240402104621.1050319-1-jakub@cloudflare.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bpf: Protect against int overflow for stack access size [+ + +]
Author: Andrei Matei <andreimatei1@gmail.com>
Date:   Tue Mar 26 22:42:45 2024 -0400

    bpf: Protect against int overflow for stack access size
    
    [ Upstream commit ecc6a2101840177e57c925c102d2d29f260d37c8 ]
    
    This patch re-introduces protection against the size of access to stack
    memory being negative; the access size can appear negative as a result
    of overflowing its signed int representation. This should not actually
    happen, as there are other protections along the way, but we should
    protect against it anyway. One code path was missing such protections
    (fixed in the previous patch in the series), causing out-of-bounds array
    accesses in check_stack_range_initialized(). This patch causes the
    verification of a program with such a non-sensical access size to fail.
    
    This check used to exist in a more indirect way, but was inadvertendly
    removed in a833a17aeac7.
    
    Fixes: a833a17aeac7 ("bpf: Fix verification of indirect var-off stack access")
    Reported-by: syzbot+33f4297b5f927648741a@syzkaller.appspotmail.com
    Reported-by: syzbot+aafd0513053a1cbf52ef@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/bpf/CAADnVQLORV5PT0iTAhRER+iLBTkByCYNBYyvBSgjN1T31K+gOw@mail.gmail.com/
    Acked-by: Andrii Nakryiko <andrii@kernel.org>
    Signed-off-by: Andrei Matei <andreimatei1@gmail.com>
    Link: https://lore.kernel.org/r/20240327024245.318299-3-andreimatei1@gmail.com
    Signed-off-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
btrfs: allocate btrfs_ioctl_defrag_range_args on stack [+ + +]
Author: Goldwyn Rodrigues <rgoldwyn@suse.com>
Date:   Tue Jul 27 16:17:30 2021 -0500

    btrfs: allocate btrfs_ioctl_defrag_range_args on stack
    
    commit c853a5783ebe123847886d432354931874367292 upstream.
    
    Instead of using kmalloc() to allocate btrfs_ioctl_defrag_range_args,
    allocate btrfs_ioctl_defrag_range_args on stack, the size is reasonably
    small and ioctls are called in process context.
    
    sizeof(btrfs_ioctl_defrag_range_args) = 48
    
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    [ This patch is needed to fix a memory leak of "range" that was
    introduced when commit 173431b274a9 ("btrfs: defrag: reject unknown
    flags of btrfs_ioctl_defrag_range_args") was backported to kernels
    lacking this patch. Now with these two patches applied in reverse order,
    range->flags needed to change back to range.flags.
    This bug was discovered and resolved using Coverity Static Analysis
    Security Testing (SAST) by Synopsys, Inc.]
    Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

btrfs: export: handle invalid inode or root reference in btrfs_get_parent() [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Fri Jan 19 21:19:18 2024 +0100

    btrfs: export: handle invalid inode or root reference in btrfs_get_parent()
    
    [ Upstream commit 26b66d1d366a375745755ca7365f67110bbf6bd5 ]
    
    The get_parent handler looks up a parent of a given dentry, this can be
    either a subvolume or a directory. The search is set up with offset -1
    but it's never expected to find such item, as it would break allowed
    range of inode number or a root id. This means it's a corruption (ext4
    also returns this error code).
    
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: fix off-by-one chunk length calculation at contains_pending_extent() [+ + +]
Author: Filipe Manana <fdmanana@suse.com>
Date:   Thu Feb 29 10:37:04 2024 +0000

    btrfs: fix off-by-one chunk length calculation at contains_pending_extent()
    
    [ Upstream commit ae6bd7f9b46a29af52ebfac25d395757e2031d0d ]
    
    At contains_pending_extent() the value of the end offset of a chunk we
    found in the device's allocation state io tree is inclusive, so when
    we calculate the length we pass to the in_range() macro, we must sum
    1 to the expression "physical_end - physical_offset".
    
    In practice the wrong calculation should be harmless as chunks sizes
    are never 1 byte and we should never have 1 byte ranges of unallocated
    space. Nevertheless fix the wrong calculation.
    
    Reported-by: Alex Lyakas <alex.lyakas@zadara.com>
    Link: https://lore.kernel.org/linux-btrfs/CAOcd+r30e-f4R-5x-S7sV22RJPe7+pgwherA6xqN2_qe7o4XTg@mail.gmail.com/
    Fixes: 1c11b63eff2a ("btrfs: replace pending/pinned chunks lists with io tree")
    CC: stable@vger.kernel.org # 6.1+
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Qu Wenruo <wqu@suse.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks() [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Tue Jan 23 23:42:29 2024 +0100

    btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
    
    [ Upstream commit 7411055db5ce64f836aaffd422396af0075fdc99 ]
    
    The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,
    as it could be caused only by two impossible conditions:
    
    - at first the search key is set up to look for a chunk tree item, with
      offset -1, this is an inexact search and the key->offset will contain
      the correct offset upon a successful search, a valid chunk tree item
      cannot have an offset -1
    
    - after first successful search, the found_key corresponds to a chunk
      item, the offset is decremented by 1 before the next loop, it's
      impossible to find a chunk item there due to alignment and size
      constraints
    
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Reviewed-by: Anand Jain <anand.jain@oracle.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

btrfs: send: handle path ref underflow in header iterate_inode_ref() [+ + +]
Author: David Sterba <dsterba@suse.com>
Date:   Tue Feb 6 22:47:13 2024 +0100

    btrfs: send: handle path ref underflow in header iterate_inode_ref()
    
    [ Upstream commit 3c6ee34c6f9cd12802326da26631232a61743501 ]
    
    Change BUG_ON to proper error handling if building the path buffer
    fails. The pointers are not printed so we don't accidentally leak kernel
    addresses.
    
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays [+ + +]
Author: Gabor Juhos <j4g8y7@gmail.com>
Date:   Thu Feb 29 19:07:47 2024 +0100

    clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays
    
    [ Upstream commit cdbc6e2d8108bc47895e5a901cfcaf799b00ca8d ]
    
    The frequency table arrays are supposed to be terminated with an
    empty element. Add such entry to the end of the arrays where it
    is missing in order to avoid possible out-of-bound access when
    the table is traversed by functions like qcom_find_freq() or
    qcom_find_freq_floor().
    
    Only compile tested.
    
    Fixes: d9db07f088af ("clk: qcom: Add ipq6018 Global Clock Controller support")
    Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
    Reviewed-by: Stephen Boyd <sboyd@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240229-freq-table-terminator-v1-2-074334f0905c@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays [+ + +]
Author: Gabor Juhos <j4g8y7@gmail.com>
Date:   Thu Feb 29 19:07:48 2024 +0100

    clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays
    
    [ Upstream commit 1040ef5ed95d6fd2628bad387d78a61633e09429 ]
    
    The frequency table arrays are supposed to be terminated with an
    empty element. Add such entry to the end of the arrays where it
    is missing in order to avoid possible out-of-bound access when
    the table is traversed by functions like qcom_find_freq() or
    qcom_find_freq_floor().
    
    Only compile tested.
    
    Fixes: 9607f6224b39 ("clk: qcom: ipq8074: add PCIE, USB and SDCC clocks")
    Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
    Reviewed-by: Stephen Boyd <sboyd@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240229-freq-table-terminator-v1-3-074334f0905c@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: gcc-sdm845: Add soft dependency on rpmhpd [+ + +]
Author: Amit Pundir <amit.pundir@linaro.org>
Date:   Tue Jan 23 11:58:14 2024 +0530

    clk: qcom: gcc-sdm845: Add soft dependency on rpmhpd
    
    [ Upstream commit 1d9054e3a4fd36e2949e616f7360bdb81bcc1921 ]
    
    With the addition of RPMh power domain to the GCC node in
    device tree, we noticed a significant delay in getting the
    UFS driver probed on AOSP which futher led to mount failures
    because Android do not support rootwait. So adding a soft
    dependency on RPMh power domain which informs modprobe to
    load rpmhpd module before gcc-sdm845.
    
    Cc: stable@vger.kernel.org # v5.4+
    Fixes: 4b6ea15c0a11 ("arm64: dts: qcom: sdm845: Add missing RPMh power domain to GCC")
    Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Link: https://lore.kernel.org/r/20240123062814.2555649-1-amit.pundir@linaro.org
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays [+ + +]
Author: Gabor Juhos <j4g8y7@gmail.com>
Date:   Thu Feb 29 19:07:51 2024 +0100

    clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays
    
    [ Upstream commit a903cfd38d8dee7e754fb89fd1bebed99e28003d ]
    
    The frequency table arrays are supposed to be terminated with an
    empty element. Add such entry to the end of the arrays where it
    is missing in order to avoid possible out-of-bound access when
    the table is traversed by functions like qcom_find_freq() or
    qcom_find_freq_floor().
    
    Only compile tested.
    
    Fixes: 2b46cd23a5a2 ("clk: qcom: Add APQ8084 Multimedia Clock Controller (MMCC) support")
    Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
    Reviewed-by: Stephen Boyd <sboyd@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240229-freq-table-terminator-v1-6-074334f0905c@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays [+ + +]
Author: Gabor Juhos <j4g8y7@gmail.com>
Date:   Thu Feb 29 19:07:52 2024 +0100

    clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays
    
    [ Upstream commit e2c02a85bf53ae86d79b5fccf0a75ac0b78e0c96 ]
    
    The frequency table arrays are supposed to be terminated with an
    empty element. Add such entry to the end of the arrays where it
    is missing in order to avoid possible out-of-bound access when
    the table is traversed by functions like qcom_find_freq() or
    qcom_find_freq_floor().
    
    Only compile tested.
    
    Fixes: d8b212014e69 ("clk: qcom: Add support for MSM8974's multimedia clock controller (MMCC)")
    Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
    Reviewed-by: Stephen Boyd <sboyd@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240229-freq-table-terminator-v1-7-074334f0905c@gmail.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
comedi: comedi_test: Prevent timers rescheduling during deletion [+ + +]
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Wed Feb 14 10:07:25 2024 +0000

    comedi: comedi_test: Prevent timers rescheduling during deletion
    
    commit f53641a6e849034a44bf80f50245a75d7a376025 upstream.
    
    The comedi_test devices have a couple of timers (ai_timer and ao_timer)
    that can be started to simulate hardware interrupts.  Their expiry
    functions normally reschedule the timer.  The driver code calls either
    del_timer_sync() or del_timer() to delete the timers from the queue, but
    does not currently prevent the timers from rescheduling themselves so
    synchronized deletion may be ineffective.
    
    Add a couple of boolean members (one for each timer: ai_timer_enable and
    ao_timer_enable) to the device private data structure to indicate
    whether the timers are allowed to reschedule themselves.  Set the member
    to true when adding the timer to the queue, and to false when deleting
    the timer from the queue in the waveform_ai_cancel() and
    waveform_ao_cancel() functions.
    
    The del_timer_sync() function is also called from the waveform_detach()
    function, but the timer enable members will already be set to false when
    that function is called, so no change is needed there.
    
    Fixes: 403fe7f34e33 ("staging: comedi: comedi_test: fix timer race conditions")
    Cc: stable@vger.kernel.org # 4.4+
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Link: https://lore.kernel.org/r/20240214100747.16203-1-abbotti@mev.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
cpufreq: brcmstb-avs-cpufreq: fix up "add check for cpufreq_cpu_get's return value" [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Mar 27 15:21:45 2024 +0100

    cpufreq: brcmstb-avs-cpufreq: fix up "add check for cpufreq_cpu_get's return value"
    
    In commit 9127599c075c ("cpufreq: brcmstb-avs-cpufreq: add check for
    cpufreq_cpu_get's return value"), build warnings occur because a
    variable is created after some logic, resulting in:
    
    drivers/cpufreq/brcmstb-avs-cpufreq.c: In function 'brcm_avs_cpufreq_get':
    drivers/cpufreq/brcmstb-avs-cpufreq.c:486:9: error: ISO C90 forbids mixed
    declarations and code [-Werror=declaration-after-statement]
      486 |         struct private_data *priv = policy->driver_data;
          |         ^~~~~~
    cc1: all warnings being treated as errors
    make[2]: *** [scripts/Makefile.build:289:
    drivers/cpufreq/brcmstb-avs-cpufreq.o] Error 1
    make[1]: *** [scripts/Makefile.build:552: drivers/cpufreq] Error 2
    make[1]: *** Waiting for unfinished jobs....
    make: *** [Makefile:1907: drivers] Error 2
    
    Fix this up.
    
    Link: https://lore.kernel.org/r/e114d9e5-26af-42be-9baa-72c3a6ec8fe5@oracle.com
    Link: https://lore.kernel.org/stable/20240327015023.GC7502@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net/T/#m15bff0fe96986ef780e848b4fff362bf8ea03f08
    Reported-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Fixes: 9127599c075c ("cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value")
    Cc: Anastasia Belova <abelova@astralinux.ru>
    Cc: Viresh Kumar <viresh.kumar@linaro.org>
    Cc: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cpufreq: dt: always allocate zeroed cpumask [+ + +]
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date:   Thu Mar 14 13:54:57 2024 +0100

    cpufreq: dt: always allocate zeroed cpumask
    
    [ Upstream commit d2399501c2c081eac703ca9597ceb83c7875a537 ]
    
    Commit 0499a78369ad ("ARM64: Dynamically allocate cpumasks and increase
    supported CPUs to 512") changed the handling of cpumasks on ARM 64bit,
    what resulted in the strange issues and warnings during cpufreq-dt
    initialization on some big.LITTLE platforms.
    
    This was caused by mixing OPPs between big and LITTLE cores, because
    OPP-sharing information between big and LITTLE cores is computed on
    cpumask, which in turn was not zeroed on allocation. Fix this by
    switching to zalloc_cpumask_var() call.
    
    Fixes: dc279ac6e5b4 ("cpufreq: dt: Refactor initialization to handle probe deferral properly")
    CC: stable@vger.kernel.org # v5.10+
    Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com>
    Reviewed-by: Dhruva Gole <d-gole@ti.com>
    Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
crypto: qat - fix double free during reset [+ + +]
Author: Svyatoslav Pankratov <svyatoslav.pankratov@intel.com>
Date:   Mon Oct 9 13:27:19 2023 +0100

    crypto: qat - fix double free during reset
    
    [ Upstream commit 01aed663e6c421aeafc9c330bda630976b50a764 ]
    
    There is no need to free the reset_data structure if the recovery is
    unsuccessful and the reset is synchronous. The function
    adf_dev_aer_schedule_reset() handles the cleanup properly. Only
    asynchronous resets require such structure to be freed inside the reset
    worker.
    
    Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework")
    Signed-off-by: Svyatoslav Pankratov <svyatoslav.pankratov@intel.com>
    Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Stable-dep-of: 7d42e097607c ("crypto: qat - resolve race condition during AER recovery")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

crypto: qat - resolve race condition during AER recovery [+ + +]
Author: Damian Muszynski <damian.muszynski@intel.com>
Date:   Fri Feb 9 13:43:42 2024 +0100

    crypto: qat - resolve race condition during AER recovery
    
    [ Upstream commit 7d42e097607c4d246d99225bf2b195b6167a210c ]
    
    During the PCI AER system's error recovery process, the kernel driver
    may encounter a race condition with freeing the reset_data structure's
    memory. If the device restart will take more than 10 seconds the function
    scheduling that restart will exit due to a timeout, and the reset_data
    structure will be freed. However, this data structure is used for
    completion notification after the restart is completed, which leads
    to a UAF bug.
    
    This results in a KFENCE bug notice.
    
      BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]
      Use-after-free read at 0x00000000bc56fddf (in kfence-#142):
      adf_device_reset_worker+0x38/0xa0 [intel_qat]
      process_one_work+0x173/0x340
    
    To resolve this race condition, the memory associated to the container
    of the work_struct is freed on the worker if the timeout expired,
    otherwise on the function that schedules the worker.
    The timeout detection can be done by checking if the caller is
    still waiting for completion or not by using completion_done() function.
    
    Fixes: d8cba25d2c68 ("crypto: qat - Intel(R) QAT driver framework")
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Damian Muszynski <damian.muszynski@intel.com>
    Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm integrity: fix out-of-range warning [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Thu Mar 28 15:30:39 2024 +0100

    dm integrity: fix out-of-range warning
    
    [ Upstream commit 8e91c2342351e0f5ef6c0a704384a7f6fc70c3b2 ]
    
    Depending on the value of CONFIG_HZ, clang complains about a pointless
    comparison:
    
    drivers/md/dm-integrity.c:4085:12: error: result of comparison of
                            constant 42949672950 with expression of type
                            'unsigned int' is always false
                            [-Werror,-Wtautological-constant-out-of-range-compare]
                            if (val >= (uint64_t)UINT_MAX * 1000 / HZ) {
    
    As the check remains useful for other configurations, shut up the
    warning by adding a second type cast to uint64_t.
    
    Fixes: 468dfca38b1a ("dm integrity: add a bitmap mode")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
    Reviewed-by: Justin Stitt <justinstitt@google.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm snapshot: fix lockup in dm_exception_table_exit [+ + +]
Author: Mikulas Patocka <mpatocka@redhat.com>
Date:   Wed Mar 20 18:43:11 2024 +0100

    dm snapshot: fix lockup in dm_exception_table_exit
    
    [ Upstream commit 6e7132ed3c07bd8a6ce3db4bb307ef2852b322dc ]
    
    There was reported lockup when we exit a snapshot with many exceptions.
    Fix this by adding "cond_resched" to the loop that frees the exceptions.
    
    Reported-by: John Pittman <jpittman@redhat.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
    Signed-off-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dm-raid: fix lockdep waring in "pers->hot_add_disk" [+ + +]
Author: Yu Kuai <yukuai3@huawei.com>
Date:   Tue Mar 5 15:23:06 2024 +0800

    dm-raid: fix lockdep waring in "pers->hot_add_disk"
    
    [ Upstream commit 95009ae904b1e9dca8db6f649f2d7c18a6e42c75 ]
    
    The lockdep assert is added by commit a448af25becf ("md/raid10: remove
    rcu protection to access rdev from conf") in print_conf(). And I didn't
    notice that dm-raid is calling "pers->hot_add_disk" without holding
    'reconfig_mutex'.
    
    "pers->hot_add_disk" read and write many fields that is protected by
    'reconfig_mutex', and raid_resume() already grab the lock in other
    contex. Hence fix this problem by protecting "pers->host_add_disk"
    with the lock.
    
    Fixes: 9092c02d9435 ("DM RAID: Add ability to restore transiently failed devices on resume")
    Fixes: a448af25becf ("md/raid10: remove rcu protection to access rdev from conf")
    Cc: stable@vger.kernel.org # v6.7+
    Signed-off-by: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Xiao Ni <xni@redhat.com>
    Acked-by: Mike Snitzer <snitzer@kernel.org>
    Signed-off-by: Song Liu <song@kernel.org>
    Link: https://lore.kernel.org/r/20240305072306.2562024-10-yukuai1@huaweicloud.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Documentation/hw-vuln: Add documentation for RFDS [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Mar 12 15:41:13 2024 -0700

    Documentation/hw-vuln: Add documentation for RFDS
    
    commit 4e42765d1be01111df0c0275bbaf1db1acef346e upstream.
    
    Add the documentation for transient execution vulnerability Register
    File Data Sampling (RFDS) that affects Intel Atom CPUs.
    
      [ pawan: s/ATOM_GRACEMONT/ALDERLAKE_N/ ]
    
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Documentation/hw-vuln: Update spectre doc [+ + +]
Author: Lin Yujun <linyujun809@huawei.com>
Date:   Tue Aug 30 20:36:14 2022 +0800

    Documentation/hw-vuln: Update spectre doc
    
    commit 06cb31cc761823ef444ba4e1df11347342a6e745 upstream.
    
    commit 7c693f54c873691 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS")
    
    adds the "ibrs " option  in
    Documentation/admin-guide/kernel-parameters.txt but omits it to
    Documentation/admin-guide/hw-vuln/spectre.rst, add it.
    
    Signed-off-by: Lin Yujun <linyujun809@huawei.com>
    Link: https://lore.kernel.org/r/20220830123614.23007-1-linyujun809@huawei.com
    Signed-off-by: Jonathan Corbet <corbet@lwn.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
driver core: Introduce device_link_wait_removal() [+ + +]
Author: Herve Codina <herve.codina@bootlin.com>
Date:   Mon Mar 25 16:21:25 2024 +0100

    driver core: Introduce device_link_wait_removal()
    
    commit 0462c56c290a99a7f03e817ae5b843116dfb575c upstream.
    
    The commit 80dd33cf72d1 ("drivers: base: Fix device link removal")
    introduces a workqueue to release the consumer and supplier devices used
    in the devlink.
    In the job queued, devices are release and in turn, when all the
    references to these devices are dropped, the release function of the
    device itself is called.
    
    Nothing is present to provide some synchronisation with this workqueue
    in order to ensure that all ongoing releasing operations are done and
    so, some other operations can be started safely.
    
    For instance, in the following sequence:
      1) of_platform_depopulate()
      2) of_overlay_remove()
    
    During the step 1, devices are released and related devlinks are removed
    (jobs pushed in the workqueue).
    During the step 2, OF nodes are destroyed but, without any
    synchronisation with devlink removal jobs, of_overlay_remove() can raise
    warnings related to missing of_node_put():
      ERROR: memory leak, expected refcount 1 instead of 2
    
    Indeed, the missing of_node_put() call is going to be done, too late,
    from the workqueue job execution.
    
    Introduce device_link_wait_removal() to offer a way to synchronize
    operations waiting for the end of devlink removals (i.e. end of
    workqueue jobs).
    Also, as a flushing operation is done on the workqueue, the workqueue
    used is moved from a system-wide workqueue to a local one.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Herve Codina <herve.codina@bootlin.com>
    Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
    Reviewed-by: Nuno Sa <nuno.sa@analog.com>
    Reviewed-by: Saravana Kannan <saravanak@google.com>
    Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Link: https://lore.kernel.org/r/20240325152140.198219-2-herve.codina@bootlin.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drivers/nvme: Add quirks for device 126f:2262 [+ + +]
Author: Jiawei Fu (iBug) <i@ibugone.com>
Date:   Sat Mar 16 03:27:49 2024 +0800

    drivers/nvme: Add quirks for device 126f:2262
    
    [ Upstream commit e89086c43f0500bc7c4ce225495b73b8ce234c1f ]
    
    This commit adds NVME_QUIRK_NO_DEEPEST_PS and NVME_QUIRK_BOGUS_NID for
    device [126f:2262], which appears to be a generic VID:PID pair used for
    many SSDs based on the Silicon Motion SM2262/SM2262EN controller.
    
    Two of my SSDs with this VID:PID pair exhibit the same behavior:
    
      * They frequently have trouble exiting the deepest power state (5),
        resulting in the entire disk unresponsive.
        Verified by setting nvme_core.default_ps_max_latency_us=10000 and
        observing them behaving normally.
      * They produce all-zero nguid and eui64 with `nvme id-ns` command.
    
    The offending products are:
    
      * HP SSD EX950 1TB
      * HIKVISION C2000Pro 2TB
    
    Signed-off-by: Jiawei Fu <i@ibugone.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Keith Busch <kbusch@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Drivers: hv: vmbus: Calculate ring buffer size for more efficient use of memory [+ + +]
Author: Michael Kelley <mhklinux@outlook.com>
Date:   Wed Feb 28 16:45:33 2024 -0800

    Drivers: hv: vmbus: Calculate ring buffer size for more efficient use of memory
    
    commit b8209544296edbd1af186e2ea9c648642c37b18c upstream.
    
    The VMBUS_RING_SIZE macro adds space for a ring buffer header to the
    requested ring buffer size.  The header size is always 1 page, and so
    its size varies based on the PAGE_SIZE for which the kernel is built.
    If the requested ring buffer size is a large power-of-2 size and the header
    size is small, the resulting size is inefficient in its use of memory.
    For example, a 512 Kbyte ring buffer with a 4 Kbyte page size results in
    a 516 Kbyte allocation, which is rounded to up 1 Mbyte by the memory
    allocator, and wastes 508 Kbytes of memory.
    
    In such situations, the exact size of the ring buffer isn't that important,
    and it's OK to allocate the 4 Kbyte header at the beginning of the 512
    Kbytes, leaving the ring buffer itself with just 508 Kbytes. The memory
    allocation can be 512 Kbytes instead of 1 Mbyte and nothing is wasted.
    
    Update VMBUS_RING_SIZE to implement this approach for "large" ring buffer
    sizes.  "Large" is somewhat arbitrarily defined as 8 times the size of
    the ring buffer header (which is of size PAGE_SIZE).  For example, for
    4 Kbyte PAGE_SIZE, ring buffers of 32 Kbytes and larger use the first
    4 Kbytes as the ring buffer header.  For 64 Kbyte PAGE_SIZE, ring buffers
    of 512 Kbytes and larger use the first 64 Kbytes as the ring buffer
    header.  In both cases, smaller sizes add space for the header so
    the ring size isn't reduced too much by using part of the space for
    the header.  For example, with a 64 Kbyte page size, we don't want
    a 128 Kbyte ring buffer to be reduced to 64 Kbytes by allocating half
    of the space for the header.  In such a case, the memory allocation
    is less efficient, but it's the best that can be done.
    
    While the new algorithm slightly changes the amount of space allocated
    for ring buffers by drivers that use VMBUS_RING_SIZE, the devices aren't
    known to be sensitive to small changes in ring buffer size, so there
    shouldn't be any effect.
    
    Fixes: c1135c7fd0e9 ("Drivers: hv: vmbus: Introduce types of GPADL")
    Fixes: 6941f67ad37d ("hv_netvsc: Calculate correct ring size when PAGE_SIZE is not 4 Kbytes")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218502
    Cc: stable@vger.kernel.org
    Signed-off-by: Michael Kelley <mhklinux@outlook.com>
    Reviewed-by: Saurabh Sengar <ssengar@linux.microsoft.com>
    Reviewed-by: Dexuan Cui <decui@microsoft.com>
    Tested-by: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
    Link: https://lore.kernel.org/r/20240229004533.313662-1-mhklinux@outlook.com
    Signed-off-by: Wei Liu <wei.liu@kernel.org>
    Message-ID: <20240229004533.313662-1-mhklinux@outlook.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Fix nanosec stat overflow [+ + +]
Author: Aric Cyr <aric.cyr@amd.com>
Date:   Thu Aug 29 11:53:52 2019 -0400

    drm/amd/display: Fix nanosec stat overflow
    
    [ Upstream commit 14d68acfd04b39f34eea7bea65dda652e6db5bf6 ]
    
    [Why]
    Nanosec stats can overflow on long running systems potentially causing
    statistic logging issues.
    
    [How]
    Use 64bit types for nanosec stats to ensure no overflow.
    
    Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Aric Cyr <aric.cyr@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Fix noise issue on HDMI AV mute [+ + +]
Author: Leo Ma <hanghong.ma@amd.com>
Date:   Fri Jul 28 08:35:07 2023 -0400

    drm/amd/display: Fix noise issue on HDMI AV mute
    
    [ Upstream commit 69e3be6893a7e668660b05a966bead82bbddb01d ]
    
    [Why]
    When mode switching is triggered there is momentary noise visible on
    some HDMI TV or displays.
    
    [How]
    Wait for 2 frames to make sure we have enough time to send out AV mute
    and sink receives a full frame.
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Wenjing Liu <wenjing.liu@amd.com>
    Acked-by: Wayne Lin <wayne.lin@amd.com>
    Signed-off-by: Leo Ma <hanghong.ma@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/amd/display: Return the correct HDCP error code [+ + +]
Author: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Date:   Wed Feb 14 13:29:51 2024 -0700

    drm/amd/display: Return the correct HDCP error code
    
    [ Upstream commit e64b3f55e458ce7e2087a0051f47edabf74545e7 ]
    
    [WHY & HOW]
    If the display is null when creating an HDCP session, return a proper
    error code.
    
    Cc: Mario Limonciello <mario.limonciello@amd.com>
    Cc: Alex Deucher <alexander.deucher@amd.com>
    Cc: stable@vger.kernel.org
    Acked-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/etnaviv: Restore some id values [+ + +]
Author: Christian Gmeiner <cgmeiner@igalia.com>
Date:   Fri Mar 1 14:28:11 2024 +0100

    drm/etnaviv: Restore some id values
    
    [ Upstream commit b735ee173f84d5d0d0733c53946a83c12d770d05 ]
    
    The hwdb selection logic as a feature that allows it to mark some fields
    as 'don't care'. If we match with such a field we memcpy(..)
    the current etnaviv_chip_identity into ident.
    
    This step can overwrite some id values read from the GPU with the
    'don't care' value.
    
    Fix this issue by restoring the affected values after the memcpy(..).
    
    As this is crucial for user space to know when this feature works as
    expected increment the minor version too.
    
    Fixes: 4078a1186dd3 ("drm/etnaviv: update hwdb selection logic")
    Cc: stable@vger.kernel.org
    Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
    Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
    Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/exynos: do not return negative values from .get_modes() [+ + +]
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Mar 8 18:03:41 2024 +0200

    drm/exynos: do not return negative values from .get_modes()
    
    [ Upstream commit 13d5b040363c7ec0ac29c2de9cf661a24a8aa531 ]
    
    The .get_modes() hooks aren't supposed to return negative error
    codes. Return 0 for no modes, whatever the reason.
    
    Cc: Inki Dae <inki.dae@samsung.com>
    Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
    Cc: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: stable@vger.kernel.org
    Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/d8665f620d9c252aa7d5a4811ff6b16e773903a2.1709913674.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/i915/gt: Reset queue_priority_hint on parking [+ + +]
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Mar 18 14:58:47 2024 +0100

    drm/i915/gt: Reset queue_priority_hint on parking
    
    commit 4a3859ea5240365d21f6053ee219bb240d520895 upstream.
    
    Originally, with strict in order execution, we could complete execution
    only when the queue was empty. Preempt-to-busy allows replacement of an
    active request that may complete before the preemption is processed by
    HW. If that happens, the request is retired from the queue, but the
    queue_priority_hint remains set, preventing direct submission until
    after the next CS interrupt is processed.
    
    This preempt-to-busy race can be triggered by the heartbeat, which will
    also act as the power-management barrier and upon completion allow us to
    idle the HW. We may process the completion of the heartbeat, and begin
    parking the engine before the CS event that restores the
    queue_priority_hint, causing us to fail the assertion that it is MIN.
    
    <3>[  166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))
    <0>[  166.210781] Dumping ftrace buffer:
    <0>[  166.210795] ---------------------------------
    ...
    <0>[  167.302811] drm_fdin-1097      2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }
    <0>[  167.302861] drm_fdin-1097      2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646
    <0>[  167.302928] drm_fdin-1097      2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0
    <0>[  167.302992] drm_fdin-1097      2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659
    <0>[  167.303044] drm_fdin-1097      2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40
    <0>[  167.303095] drm_fdin-1097      2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }
    <0>[  167.303159] kworker/-89       11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2
    <0>[  167.303208] kworker/-89       11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin
    <0>[  167.303272] kworker/-89       11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2
    <0>[  167.303321] kworker/-89       11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin
    <0>[  167.303384] kworker/-89       11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660
    <0>[  167.303434] kworker/-89       11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }
    <0>[  167.303484] kworker/-89       11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked
    <0>[  167.303534]   <idle>-0         5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040
    <0>[  167.303583] kworker/-89       11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns }
    <0>[  167.303756] kworker/-89       11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns }
    <0>[  167.303806] kworker/-89       11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))
    <0>[  167.303811] ---------------------------------
    <4>[  167.304722] ------------[ cut here ]------------
    <2>[  167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!
    <4>[  167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    <4>[  167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G        W          6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1
    <4>[  167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022
    <4>[  167.304738] Workqueue: i915-unordered retire_work_handler [i915]
    <4>[  167.304839] RIP: 0010:__engine_park+0x3fd/0x680 [i915]
    <4>[  167.304937] Code: 00 48 c7 c2 b0 e5 86 a0 48 8d 3d 00 00 00 00 e8 79 48 d4 e0 bf 01 00 00 00 e8 ef 0a d4 e0 31 f6 bf 09 00 00 00 e8 03 49 c0 e0 <0f> 0b 0f 0b be 01 00 00 00 e8 f5 61 fd ff 31 c0 e9 34 fd ff ff 48
    <4>[  167.304940] RSP: 0018:ffffc9000059fce0 EFLAGS: 00010246
    <4>[  167.304942] RAX: 0000000000000200 RBX: 0000000000000000 RCX: 0000000000000006
    <4>[  167.304944] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000009
    <4>[  167.304946] RBP: ffff8881330ca1b0 R08: 0000000000000001 R09: 0000000000000001
    <4>[  167.304947] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8881330ca000
    <4>[  167.304948] R13: ffff888110f02aa0 R14: ffff88812d1d0205 R15: ffff88811277d4f0
    <4>[  167.304950] FS:  0000000000000000(0000) GS:ffff88844f780000(0000) knlGS:0000000000000000
    <4>[  167.304952] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    <4>[  167.304953] CR2: 00007fc362200c40 CR3: 000000013306e003 CR4: 0000000000770ef0
    <4>[  167.304955] PKRU: 55555554
    <4>[  167.304957] Call Trace:
    <4>[  167.304958]  <TASK>
    <4>[  167.305573]  ____intel_wakeref_put_last+0x1d/0x80 [i915]
    <4>[  167.305685]  i915_request_retire.part.0+0x34f/0x600 [i915]
    <4>[  167.305800]  retire_requests+0x51/0x80 [i915]
    <4>[  167.305892]  intel_gt_retire_requests_timeout+0x27f/0x700 [i915]
    <4>[  167.305985]  process_scheduled_works+0x2db/0x530
    <4>[  167.305990]  worker_thread+0x18c/0x350
    <4>[  167.305993]  kthread+0xfe/0x130
    <4>[  167.305997]  ret_from_fork+0x2c/0x50
    <4>[  167.306001]  ret_from_fork_asm+0x1b/0x30
    <4>[  167.306004]  </TASK>
    
    It is necessary for the queue_priority_hint to be lower than the next
    request submission upon waking up, as we rely on the hint to decide when
    to kick the tasklet to submit that first request.
    
    Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
    Closes: https://gitlab.freedesktop.org/drm/intel/issues/10154
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
    Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
    Cc: <stable@vger.kernel.org> # v5.4+
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
    Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240318135906.716055-2-janusz.krzysztofik@linux.intel.com
    (cherry picked from commit 98850e96cf811dc2d0a7d0af491caff9f5d49c1e)
    Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/imx/ipuv3: do not return negative values from .get_modes() [+ + +]
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Mar 8 18:03:43 2024 +0200

    drm/imx/ipuv3: do not return negative values from .get_modes()
    
    [ Upstream commit c2da9ada64962fcd2e6395ed9987b9874ea032d3 ]
    
    The .get_modes() hooks aren't supposed to return negative error
    codes. Return 0 for no modes, whatever the reason.
    
    Cc: Philipp Zabel <p.zabel@pengutronix.de>
    Cc: stable@vger.kernel.org
    Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
    Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/311f6eec96d47949b16a670529f4d89fcd97aefa.1709913674.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/panel: do not return negative error codes from drm_panel_get_modes() [+ + +]
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Mar 8 18:03:40 2024 +0200

    drm/panel: do not return negative error codes from drm_panel_get_modes()
    
    [ Upstream commit fc4e97726530241d96dd7db72eb65979217422c9 ]
    
    None of the callers of drm_panel_get_modes() expect it to return
    negative error codes. Either they propagate the return value in their
    struct drm_connector_helper_funcs .get_modes() hook (which is also not
    supposed to return negative codes), or add it to other counts leading to
    bogus values.
    
    On the other hand, many of the struct drm_panel_funcs .get_modes() hooks
    do return negative error codes, so handle them gracefully instead of
    propagating further.
    
    Return 0 for no modes, whatever the reason.
    
    Cc: Neil Armstrong <neil.armstrong@linaro.org>
    Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Cc: stable@vger.kernel.org
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
    Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/79f559b72d8c493940417304e222a4b04dfa19c4.1709913674.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/vc4: hdmi: do not return negative values from .get_modes() [+ + +]
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Fri Mar 8 18:03:44 2024 +0200

    drm/vc4: hdmi: do not return negative values from .get_modes()
    
    [ Upstream commit abf493988e380f25242c1023275c68bd3579c9ce ]
    
    The .get_modes() hooks aren't supposed to return negative error
    codes. Return 0 for no modes, whatever the reason.
    
    Cc: Maxime Ripard <mripard@kernel.org>
    Cc: stable@vger.kernel.org
    Acked-by: Maxime Ripard <mripard@kernel.org>
    Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/dcda6d4003e2c6192987916b35c7304732800e08.1709913674.git.jani.nikula@intel.com
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/vmwgfx/vmwgfx_cmdbuf_res: Remove unused variable 'ret' [+ + +]
Author: Lee Jones <lee@kernel.org>
Date:   Fri Jan 15 18:13:12 2021 +0000

    drm/vmwgfx/vmwgfx_cmdbuf_res: Remove unused variable 'ret'
    
    [ Upstream commit 43ebfe61c3928573a5ef8d80c2f5300aa5c904c0 ]
    
    Fixes the following W=1 kernel build warning(s):
    
     drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c: In function ‘vmw_cmdbuf_res_revert’:
     drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c:162:6: warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
    
    Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
    Cc: Roland Scheidegger <sroland@vmware.com>
    Cc: Zack Rusin <zackr@vmware.com>
    Cc: David Airlie <airlied@linux.ie>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: dri-devel@lists.freedesktop.org
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Zack Rusin <zackr@vmware.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210115181313.3431493-40-lee.jones@linaro.org
    Stable-dep-of: 517621b70600 ("drm/vmwgfx: Fix possible null pointer derefence with invalid contexts")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/vmwgfx: Fix possible null pointer derefence with invalid contexts [+ + +]
Author: Zack Rusin <zack.rusin@broadcom.com>
Date:   Wed Jan 10 15:03:05 2024 -0500

    drm/vmwgfx: Fix possible null pointer derefence with invalid contexts
    
    [ Upstream commit 517621b7060096e48e42f545fa6646fc00252eac ]
    
    vmw_context_cotable can return either an error or a null pointer and its
    usage sometimes went unchecked. Subsequent code would then try to access
    either a null pointer or an error value.
    
    The invalid dereferences were only possible with malformed userspace
    apps which never properly initialized the rendering contexts.
    
    Check the results of vmw_context_cotable to fix the invalid derefs.
    
    Thanks:
    ziming zhang(@ezrak1e) from Ant Group Light-Year Security Lab
    who was the first person to discover it.
    Niels De Graef who reported it and helped to track down the poc.
    
    Fixes: 9c079b8ce8bf ("drm/vmwgfx: Adapt execbuf to the new validation api")
    Cc: <stable@vger.kernel.org> # v4.20+
    Reported-by: Niels De Graef  <ndegraef@redhat.com>
    Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
    Cc: Martin Krastev <martin.krastev@broadcom.com>
    Cc: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
    Cc: Ian Forbes <ian.forbes@broadcom.com>
    Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>
    Cc: dri-devel@lists.freedesktop.org
    Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com>
    Reviewed-by: Martin Krastev <martin.krastev@broadcom.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20240110200305.94086-1-zack.rusin@broadcom.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vmwgfx: Fix some static checker warnings [+ + +]
Author: Zack Rusin <zack.rusin@broadcom.com>
Date:   Wed Jun 9 13:23:02 2021 -0400

    drm/vmwgfx: Fix some static checker warnings
    
    [ Upstream commit 74231041d14030f1ae6582b9233bfe782ac23e33 ]
    
    Fix some minor issues that Coverity spotted in the code. None
    of that are serious but they're all valid concerns so fixing
    them makes sense.
    
    Signed-off-by: Zack Rusin <zackr@vmware.com>
    Reviewed-by: Roland Scheidegger <sroland@vmware.com>
    Reviewed-by: Martin Krastev <krastevm@vmware.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20210609172307.131929-5-zackr@vmware.com
    Stable-dep-of: 517621b70600 ("drm/vmwgfx: Fix possible null pointer derefence with invalid contexts")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vmwgfx: stop using ttm_bo_create v2 [+ + +]
Author: Christian König <christian.koenig@amd.com>
Date:   Mon Sep 21 14:14:32 2020 +0200

    drm/vmwgfx: stop using ttm_bo_create v2
    
    [ Upstream commit b254557cb244e2c18e59ee1cc2293128c52d2473 ]
    
    Implement in the driver instead since it is the only user of that function.
    
    v2: fix usage of ttm_bo_init_reserved
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    Reviewed-by: Huang Rui <ray.huang@amd.com>
    Link: https://patchwork.freedesktop.org/patch/391614/?series=81973&rev=1
    Stable-dep-of: 517621b70600 ("drm/vmwgfx: Fix possible null pointer derefence with invalid contexts")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

drm/vmwgfx: switch over to the new pin interface v2 [+ + +]
Author: Christian König <christian.koenig@amd.com>
Date:   Mon Sep 21 14:37:25 2020 +0200

    drm/vmwgfx: switch over to the new pin interface v2
    
    [ Upstream commit fbe86ca567919b22bbba1220ce55020b1868879f ]
    
    Stop using TTM_PL_FLAG_NO_EVICT.
    
    v2: fix unconditional pinning
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Dave Airlie <airlied@redhat.com>
    Reviewed-by: Huang Rui <ray.huang@amd.com>
    Link: https://patchwork.freedesktop.org/patch/391601/?series=81973&rev=1
    Stable-dep-of: 517621b70600 ("drm/vmwgfx: Fix possible null pointer derefence with invalid contexts")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
efivarfs: Request at most 512 bytes for variable names [+ + +]
Author: Tim Schumacher <timschumi@gmx.de>
Date:   Fri Jan 26 17:25:23 2024 +0100

    efivarfs: Request at most 512 bytes for variable names
    
    commit f45812cc23fb74bef62d4eb8a69fe7218f4b9f2a upstream.
    
    Work around a quirk in a few old (2011-ish) UEFI implementations, where
    a call to `GetNextVariableName` with a buffer size larger than 512 bytes
    will always return EFI_INVALID_PARAMETER.
    
    There is some lore around EFI variable names being up to 1024 bytes in
    size, but this has no basis in the UEFI specification, and the upper
    bounds are typically platform specific, and apply to the entire variable
    (name plus payload).
    
    Given that Linux does not permit creating files with names longer than
    NAME_MAX (255) bytes, 512 bytes (== 256 UTF-16 characters) is a
    reasonable limit.
    
    Cc: <stable@vger.kernel.org> # 6.1+
    Signed-off-by: Tim Schumacher <timschumi@gmx.de>
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    [timschumi@gmx.de: adjusted diff for changed context and code move]
    Signed-off-by: Tim Schumacher <timschumi@gmx.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
erspan: make sure erspan_base_hdr is present in skb->head [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Mar 28 11:22:48 2024 +0000

    erspan: make sure erspan_base_hdr is present in skb->head
    
    commit 17af420545a750f763025149fa7b833a4fc8b8f0 upstream.
    
    syzbot reported a problem in ip6erspan_rcv() [1]
    
    Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make
    sure erspan_base_hdr is present in skb linear part (skb->head)
    before getting @ver field from it.
    
    Add the missing pskb_may_pull() calls.
    
    v2: Reload iph pointer in erspan_rcv() after pskb_may_pull()
        because skb->head might have changed.
    
    [1]
    
     BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
     BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]
     BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
     BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
      pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
      pskb_may_pull include/linux/skbuff.h:2756 [inline]
      ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
      gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
      ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438
      ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
      ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
      dst_input include/net/dst.h:460 [inline]
      ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79
      NF_HOOK include/linux/netfilter.h:314 [inline]
      ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310
      __netif_receive_skb_one_core net/core/dev.c:5538 [inline]
      __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652
      netif_receive_skb_internal net/core/dev.c:5738 [inline]
      netif_receive_skb+0x58/0x660 net/core/dev.c:5798
      tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549
      tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002
      tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
      call_write_iter include/linux/fs.h:2108 [inline]
      new_sync_write fs/read_write.c:497 [inline]
      vfs_write+0xb63/0x1520 fs/read_write.c:590
      ksys_write+0x20f/0x4c0 fs/read_write.c:643
      __do_sys_write fs/read_write.c:655 [inline]
      __se_sys_write fs/read_write.c:652 [inline]
      __x64_sys_write+0x93/0xe0 fs/read_write.c:652
     do_syscall_64+0xd5/0x1f0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    Uninit was created at:
      slab_post_alloc_hook mm/slub.c:3804 [inline]
      slab_alloc_node mm/slub.c:3845 [inline]
      kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
      kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
      __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
      alloc_skb include/linux/skbuff.h:1318 [inline]
      alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
      sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
      tun_alloc_skb drivers/net/tun.c:1525 [inline]
      tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846
      tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
      call_write_iter include/linux/fs.h:2108 [inline]
      new_sync_write fs/read_write.c:497 [inline]
      vfs_write+0xb63/0x1520 fs/read_write.c:590
      ksys_write+0x20f/0x4c0 fs/read_write.c:643
      __do_sys_write fs/read_write.c:655 [inline]
      __se_sys_write fs/read_write.c:652 [inline]
      __x64_sys_write+0x93/0xe0 fs/read_write.c:652
     do_syscall_64+0xd5/0x1f0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0
    
    Fixes: cb73ee40b1b3 ("net: ip_gre: use erspan key field for tunnel lookup")
    Reported-by: syzbot+1c1cf138518bf0c53d68@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/000000000000772f2c0614b66ef7@google.com/
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Lorenzo Bianconi <lorenzo@kernel.org>
    Link: https://lore.kernel.org/r/20240328112248.1101491-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
exec: Fix NOMMU linux_binprm::exec in transfer_args_to_stack() [+ + +]
Author: Max Filippov <jcmvbkbc@gmail.com>
Date:   Wed Mar 20 11:26:07 2024 -0700

    exec: Fix NOMMU linux_binprm::exec in transfer_args_to_stack()
    
    commit 2aea94ac14d1e0a8ae9e34febebe208213ba72f7 upstream.
    
    In NOMMU kernel the value of linux_binprm::p is the offset inside the
    temporary program arguments array maintained in separate pages in the
    linux_binprm::page. linux_binprm::exec being a copy of linux_binprm::p
    thus must be adjusted when that array is copied to the user stack.
    Without that adjustment the value passed by the NOMMU kernel to the ELF
    program in the AT_EXECFN entry of the aux array doesn't make any sense
    and it may break programs that try to access memory pointed to by that
    entry.
    
    Adjust linux_binprm::exec before the successful return from the
    transfer_args_to_stack().
    
    Cc: <stable@vger.kernel.org>
    Fixes: b6a2fea39318 ("mm: variable length argument support")
    Fixes: 5edc2a5123a7 ("binfmt_elf_fdpic: wire up AT_EXECFD, AT_EXECFN, AT_SECURE")
    Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
    Link: https://lore.kernel.org/r/20240320182607.1472887-1-jcmvbkbc@gmail.com
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ext4: add a hint for block bitmap corrupt state in mb_groups [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Fri Jan 19 14:11:54 2024 +0800

    ext4: add a hint for block bitmap corrupt state in mb_groups
    
    [ Upstream commit 68ee261fb15457ecb17e3683cb4e6a4792ca5b71 ]
    
    If one group is marked as block bitmap corrupted, its free blocks cannot
    be used and its free count is also deducted from the global
    sbi->s_freeclusters_counter. User might be confused about the absent
    free space because we can't query the information about corrupted block
    groups except unreliable error messages in syslog. So add a hint to show
    block bitmap corrupted groups in mb_groups.
    
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240119061154.1525781-1-yi.zhang@huaweicloud.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: correct best extent lstart adjustment logic [+ + +]
Author: Baokun Li <libaokun1@huawei.com>
Date:   Thu Feb 1 22:18:45 2024 +0800

    ext4: correct best extent lstart adjustment logic
    
    [ Upstream commit 4fbf8bc733d14bceb16dda46a3f5e19c6a9621c5 ]
    
    When yangerkun review commit 93cdf49f6eca ("ext4: Fix best extent lstart
    adjustment logic in ext4_mb_new_inode_pa()"), it was found that the best
    extent did not completely cover the original request after adjusting the
    best extent lstart in ext4_mb_new_inode_pa() as follows:
    
      original request: 2/10(8)
      normalized request: 0/64(64)
      best extent: 0/9(9)
    
    When we check if best ex can be kept at start of goal, ac_o_ex.fe_logical
    is 2 less than the adjusted best extent logical end 9, so we think the
    adjustment is done. But obviously 0/9(9) doesn't cover 2/10(8), so we
    should determine here if the original request logical end is less than or
    equal to the adjusted best extent logical end.
    
    In addition, add a comment stating when adjusted best_ex will not cover
    the original request, and remove the duplicate assertion because adjusting
    lstart makes no change to b_ex.fe_len.
    
    Link: https://lore.kernel.org/r/3630fa7f-b432-7afd-5f79-781bc3b2c5ea@huawei.com
    Fixes: 93cdf49f6eca ("ext4: Fix best extent lstart adjustment logic in ext4_mb_new_inode_pa()")
    Cc:  <stable@kernel.org>
    Signed-off-by: yangerkun <yangerkun@huawei.com>
    Signed-off-by: Baokun Li <libaokun1@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240201141845.1879253-1-libaokun1@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: fix corruption during on-line resize [+ + +]
Author: Maximilian Heyne <mheyne@amazon.de>
Date:   Thu Feb 15 15:50:09 2024 +0000

    ext4: fix corruption during on-line resize
    
    [ Upstream commit a6b3bfe176e8a5b05ec4447404e412c2a3fc92cc ]
    
    We observed a corruption during on-line resize of a file system that is
    larger than 16 TiB with 4k block size. With having more then 2^32 blocks
    resize_inode is turned off by default by mke2fs. The issue can be
    reproduced on a smaller file system for convenience by explicitly
    turning off resize_inode. An on-line resize across an 8 GiB boundary (the
    size of a meta block group in this setup) then leads to a corruption:
    
      dev=/dev/<some_dev> # should be >= 16 GiB
      mkdir -p /corruption
      /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15))
      mount -t ext4 $dev /corruption
    
      dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15))
      sha1sum /corruption/test
      # 79d2658b39dcfd77274e435b0934028adafaab11  /corruption/test
    
      /sbin/resize2fs $dev $((2*2**21))
      # drop page cache to force reload the block from disk
      echo 1 > /proc/sys/vm/drop_caches
    
      sha1sum /corruption/test
      # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3  /corruption/test
    
    2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per
    block group and 2^6 are the number of block groups that make a meta
    block group.
    
    The last checksum might be different depending on how the file is laid
    out across the physical blocks. The actual corruption occurs at physical
    block 63*2^15 = 2064384 which would be the location of the backup of the
    meta block group's block descriptor. During the on-line resize the file
    system will be converted to meta_bg starting at s_first_meta_bg which is
    2 in the example - meaning all block groups after 16 GiB. However, in
    ext4_flex_group_add we might add block groups that are not part of the
    first meta block group yet. In the reproducer we achieved this by
    substracting the size of a whole block group from the point where the
    meta block group would start. This must be considered when updating the
    backup block group descriptors to follow the non-meta_bg layout. The fix
    is to add a test whether the group to add is already part of the meta
    block group or not.
    
    Fixes: 01f795f9e0d67 ("ext4: add online resizing support for meta_bg and 64-bit file systems")
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
    Tested-by: Srivathsa Dara <srivathsa.d.dara@oracle.com>
    Reviewed-by: Srivathsa Dara <srivathsa.d.dara@oracle.com>
    Link: https://lore.kernel.org/r/20240215155009.94493-1-mheyne@amazon.de
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ext4: forbid commit inconsistent quota data when errors=remount-ro [+ + +]
Author: Ye Bin <yebin10@huawei.com>
Date:   Fri Jan 19 14:29:08 2024 +0800

    ext4: forbid commit inconsistent quota data when errors=remount-ro
    
    [ Upstream commit d8b945fa475f13d787df00c26a6dc45a3e2e1d1d ]
    
    There's issue as follows When do IO fault injection test:
    Quota error (device dm-3): find_block_dqentry: Quota for id 101 referenced but not present
    Quota error (device dm-3): qtree_read_dquot: Can't read quota structure for id 101
    Quota error (device dm-3): do_check_range: Getting block 2021161007 out of range 1-186
    Quota error (device dm-3): qtree_read_dquot: Can't read quota structure for id 661
    
    Now, ext4_write_dquot()/ext4_acquire_dquot()/ext4_release_dquot() may commit
    inconsistent quota data even if process failed. This may lead to filesystem
    corruption.
    To ensure filesystem consistent when errors=remount-ro there is need to call
    ext4_handle_error() to abort journal.
    
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20240119062908.3598806-1-yebin10@huawei.com
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fat: fix uninitialized field in nostale filehandles [+ + +]
Author: Jan Kara <jack@suse.cz>
Date:   Mon Feb 5 13:26:26 2024 +0100

    fat: fix uninitialized field in nostale filehandles
    
    [ Upstream commit fde2497d2bc3a063d8af88b258dbadc86bd7b57c ]
    
    When fat_encode_fh_nostale() encodes file handle without a parent it
    stores only first 10 bytes of the file handle. However the length of the
    file handle must be a multiple of 4 so the file handle is actually 12
    bytes long and the last two bytes remain uninitialized. This is not
    great at we potentially leak uninitialized information with the handle
    to userspace. Properly initialize the full handle length.
    
    Link: https://lkml.kernel.org/r/20240205122626.13701-1-jack@suse.cz
    Reported-by: syzbot+3ce5dea5b1539ff36769@syzkaller.appspotmail.com
    Fixes: ea3983ace6b7 ("fat: restructure export_operations")
    Signed-off-by: Jan Kara <jack@suse.cz>
    Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
    Cc: Amir Goldstein <amir73il@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbdev: viafb: fix typo in hw_bitblt_1 and hw_bitblt_2 [+ + +]
Author: Aleksandr Burakov <a.burakov@rosalinux.ru>
Date:   Fri Mar 1 14:35:43 2024 +0300

    fbdev: viafb: fix typo in hw_bitblt_1 and hw_bitblt_2
    
    [ Upstream commit bc87bb342f106a0402186bcb588fcbe945dced4b ]
    
    There are some actions with value 'tmp' but 'dst_addr' is checked instead.
    It is obvious that a copy-paste error was made here and the value
    of variable 'tmp' should be checked here.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Aleksandr Burakov <a.burakov@rosalinux.ru>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fbmon: prevent division by zero in fb_videomode_from_videomode() [+ + +]
Author: Roman Smirnov <r.smirnov@omp.ru>
Date:   Tue Mar 19 11:13:44 2024 +0300

    fbmon: prevent division by zero in fb_videomode_from_videomode()
    
    [ Upstream commit c2d953276b8b27459baed1277a4fdd5dd9bd4126 ]
    
    The expression htotal * vtotal can have a zero value on
    overflow. It is necessary to prevent division by zero like in
    fb_var_to_videomode().
    
    Found by Linux Verification Center (linuxtesting.org) with Svace.
    
    Signed-off-by: Roman Smirnov <r.smirnov@omp.ru>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion [+ + +]
Author: Bart Van Assche <bvanassche@acm.org>
Date:   Mon Mar 4 15:57:15 2024 -0800

    fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
    
    commit 961ebd120565cb60cebe21cb634fbc456022db4a upstream.
    
    The first kiocb_set_cancel_fn() argument may point at a struct kiocb
    that is not embedded inside struct aio_kiocb. With the current code,
    depending on the compiler, the req->ki_ctx read happens either before
    the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such
    that it is guaranteed that the IOCB_AIO_RW test happens first.
    
    Reported-by: Eric Biggers <ebiggers@kernel.org>
    Cc: Benjamin LaHaise <ben@communityfibre.ca>
    Cc: Eric Biggers <ebiggers@google.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Avi Kivity <avi@scylladb.com>
    Cc: Sandeep Dhavale <dhavale@google.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Kent Overstreet <kent.overstreet@linux.dev>
    Cc: stable@vger.kernel.org
    Fixes: b820de741ae4 ("fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio")
    Signed-off-by: Bart Van Assche <bvanassche@acm.org>
    Link: https://lore.kernel.org/r/20240304235715.3790858-1-bvanassche@acm.org
    Reviewed-by: Jens Axboe <axboe@kernel.dk>
    Reviewed-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fuse: don't unhash root [+ + +]
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Wed Feb 28 16:50:49 2024 +0100

    fuse: don't unhash root
    
    [ Upstream commit b1fe686a765e6c0d71811d825b5a1585a202b777 ]
    
    The root inode is assumed to be always hashed.  Do not unhash the root
    inode even if it is marked BAD.
    
    Fixes: 5d069dbe8aaf ("fuse: fix bad inode")
    Cc: <stable@vger.kernel.org> # v5.11
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fuse: fix root lookup with nonzero generation [+ + +]
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Wed Feb 28 16:50:49 2024 +0100

    fuse: fix root lookup with nonzero generation
    
    [ Upstream commit 68ca1b49e430f6534d0774a94147a823e3b8b26e ]
    
    The root inode has a fixed nodeid and generation (1, 0).
    
    Prior to the commit 15db16837a35 ("fuse: fix illegal access to inode with
    reused nodeid") generation number on lookup was ignored.  After this commit
    lookup with the wrong generation number resulted in the inode being
    unhashed.  This is correct for non-root inodes, but replacing the root
    inode is wrong and results in weird behavior.
    
    Fix by reverting to the old behavior if ignoring the generation for the
    root inode, but issuing a warning in dmesg.
    
    Reported-by: Antonio SJ Musumeci <trapexit@spawn.link>
    Closes: https://lore.kernel.org/all/CAOQ4uxhek5ytdN8Yz2tNEOg5ea4NkBb4nk0FGPjPk_9nz-VG3g@mail.gmail.com/
    Fixes: 15db16837a35 ("fuse: fix illegal access to inode with reused nodeid")
    Cc: <stable@vger.kernel.org> # v5.14
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
hexagon: vmlinux.lds.S: handle attributes section [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Mar 19 17:37:46 2024 -0700

    hexagon: vmlinux.lds.S: handle attributes section
    
    commit 549aa9678a0b3981d4821bf244579d9937650562 upstream.
    
    After the linked LLVM change, the build fails with
    CONFIG_LD_ORPHAN_WARN_LEVEL="error", which happens with allmodconfig:
    
      ld.lld: error: vmlinux.a(init/main.o):(.hexagon.attributes) is being placed in '.hexagon.attributes'
    
    Handle the attributes section in a similar manner as arm and riscv by
    adding it after the primary ELF_DETAILS grouping in vmlinux.lds.S, which
    fixes the error.
    
    Link: https://lkml.kernel.org/r/20240319-hexagon-handle-attributes-section-vmlinux-lds-s-v1-1-59855dab8872@kernel.org
    Fixes: 113616ec5b64 ("hexagon: select ARCH_WANT_LD_ORPHAN_WARN")
    Link: https://github.com/llvm/llvm-project/commit/31f4b329c8234fab9afa59494d7f8bdaeaefeaad
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Brian Cain <bcain@quicinc.com>
    Cc: Bill Wendling <morbo@google.com>
    Cc: Justin Stitt <justinstitt@google.com>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
hwmon: (amc6821) add of_match table [+ + +]
Author: Josua Mayer <josua@solid-run.com>
Date:   Thu Mar 7 12:06:58 2024 +0100

    hwmon: (amc6821) add of_match table
    
    [ Upstream commit 3f003fda98a7a8d5f399057d92e6ed56b468657c ]
    
    Add of_match table for "ti,amc6821" compatible string.
    This fixes automatic driver loading by userspace when using device-tree,
    and if built as a module like major linux distributions do.
    
    While devices probe just fine with i2c_device_id table, userspace can't
    match the "ti,amc6821" compatible string from dt with the plain
    "amc6821" device id. As a result, the kernel module can not be loaded.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Josua Mayer <josua@solid-run.com>
    Link: https://lore.kernel.org/r/20240307-amc6821-of-match-v1-1-5f40464a3110@solid-run.com
    [groeck: Cleaned up patch description]
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: fix i40e_count_filters() to count only active/new filters [+ + +]
Author: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Date:   Wed Mar 13 10:44:00 2024 +0100

    i40e: fix i40e_count_filters() to count only active/new filters
    
    commit eb58c598ce45b7e787568fe27016260417c3d807 upstream.
    
    The bug usually affects untrusted VFs, because they are limited to 18 MACs,
    it affects them badly, not letting to create MAC all filters.
    Not stable to reproduce, it happens when VF user creates MAC filters
    when other MACVLAN operations are happened in parallel.
    But consequence is that VF can't receive desired traffic.
    
    Fix counter to be bumped only for new or active filters.
    
    Fixes: 621650cabee5 ("i40e: Refactoring VF MAC filters counting to make more reliable")
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
    Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: fix vf may be used uninitialized in this function warning [+ + +]
Author: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Date:   Wed Mar 13 10:56:39 2024 +0100

    i40e: fix vf may be used uninitialized in this function warning
    
    commit f37c4eac99c258111d414d31b740437e1925b8e8 upstream.
    
    To fix the regression introduced by commit 52424f974bc5, which causes
    servers hang in very hard to reproduce conditions with resets races.
    Using two sources for the information is the root cause.
    In this function before the fix bumping v didn't mean bumping vf
    pointer. But the code used this variables interchangeably, so stale vf
    could point to different/not intended vf.
    
    Remove redundant "v" variable and iterate via single VF pointer across
    whole function instead to guarantee VF pointer validity.
    
    Fixes: 52424f974bc5 ("i40e: Fix VF hang when reset is triggered on another VF")
    Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
    Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
init: open /initrd.image with O_LARGEFILE [+ + +]
Author: John Sperbeck <jsperbeck@google.com>
Date:   Sun Mar 17 15:15:22 2024 -0700

    init: open /initrd.image with O_LARGEFILE
    
    commit 4624b346cf67400ef46a31771011fb798dd2f999 upstream.
    
    If initrd data is larger than 2Gb, we'll eventually fail to write to the
    /initrd.image file when we hit that limit, unless O_LARGEFILE is set.
    
    Link: https://lkml.kernel.org/r/20240317221522.896040-1-jsperbeck@google.com
    Signed-off-by: John Sperbeck <jsperbeck@google.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Input: allocate keycode for Display refresh rate toggle [+ + +]
Author: Gergo Koteles <soyer@irl.hu>
Date:   Sun Mar 10 12:31:41 2024 +0100

    Input: allocate keycode for Display refresh rate toggle
    
    [ Upstream commit cfeb98b95fff25c442f78a6f616c627bc48a26b7 ]
    
    Newer Lenovo Yogas and Legions with 60Hz/90Hz displays send a wmi event
    when Fn + R is pressed. This is intended for use to switch between the
    two refresh rates.
    
    Allocate a new KEY_REFRESH_RATE_TOGGLE keycode for it.
    
    Signed-off-by: Gergo Koteles <soyer@irl.hu>
    Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Link: https://lore.kernel.org/r/15a5d08c84cf4d7b820de34ebbcf8ae2502fb3ca.1710065750.git.soyer@irl.hu
    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>

Input: synaptics-rmi4 - fail probing if memory allocation for "phys" fails [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Thu Jan 18 11:37:59 2024 -0800

    Input: synaptics-rmi4 - fail probing if memory allocation for "phys" fails
    
    [ Upstream commit bc4996184d56cfaf56d3811ac2680c8a0e2af56e ]
    
    While input core can work with input->phys set to NULL userspace might
    depend on it, so better fail probing if allocation fails. The system must
    be in a pretty bad shape for it to happen anyway.
    
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Link: https://lore.kernel.org/r/20240117073124.143636-1-chentao@kylinos.cn
    Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
io_uring: ensure '0' is returned on file registration success [+ + +]
Author: Jens Axboe <axboe@kernel.dk>
Date:   Tue Apr 2 08:28:04 2024 -0600

    io_uring: ensure '0' is returned on file registration success
    
    A previous backport mistakenly removed code that cleared 'ret' to zero,
    as the SCM logging was performed. Fix up the return value so we don't
    return an errant error on fixed file registration.
    
    Fixes: a6771f343af9 ("io_uring: drop any code related to SCM_RIGHTS")
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ionic: set adminq irq affinity [+ + +]
Author: Shannon Nelson <shannon.nelson@amd.com>
Date:   Wed Feb 14 09:59:01 2024 -0800

    ionic: set adminq irq affinity
    
    [ Upstream commit c699f35d658f3c21b69ed24e64b2ea26381e941d ]
    
    We claim to have the AdminQ on our irq0 and thus cpu id 0,
    but we need to be sure we set the affinity hint to try to
    keep it there.
    
    Signed-off-by: Shannon Nelson <shannon.nelson@amd.com>
    Reviewed-by: Brett Creeley <brett.creeley@amd.com>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ipv6: Fix infinite recursion in fib6_dump_done(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@amazon.com>
Date:   Mon Apr 1 14:10:04 2024 -0700

    ipv6: Fix infinite recursion in fib6_dump_done().
    
    commit d21d40605bca7bd5fc23ef03d4c1ca1f48bc2cae upstream.
    
    syzkaller reported infinite recursive calls of fib6_dump_done() during
    netlink socket destruction.  [1]
    
    From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then
    the response was generated.  The following recvmmsg() resumed the dump
    for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due
    to the fault injection.  [0]
    
      12:01:34 executing program 3:
      r0 = socket$nl_route(0x10, 0x3, 0x0)
      sendmsg$nl_route(r0, ... snip ...)
      recvmmsg(r0, ... snip ...) (fail_nth: 8)
    
    Here, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call
    of inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3].  syzkaller stopped
    receiving the response halfway through, and finally netlink_sock_destruct()
    called nlk_sk(sk)->cb.done().
    
    fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it
    is still not NULL.  fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by
    nlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling
    itself recursively and hitting the stack guard page.
    
    To avoid the issue, let's set the destructor after kzalloc().
    
    [0]:
    FAULT_INJECTION: forcing a failure.
    name failslab, interval 1, probability 0, space 0, times 0
    CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    Call Trace:
     <TASK>
     dump_stack_lvl (lib/dump_stack.c:117)
     should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)
     should_failslab (mm/slub.c:3733)
     kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)
     inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)
     rtnl_dump_all (net/core/rtnetlink.c:4029)
     netlink_dump (net/netlink/af_netlink.c:2269)
     netlink_recvmsg (net/netlink/af_netlink.c:1988)
     ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)
     ___sys_recvmsg (net/socket.c:2846)
     do_recvmmsg (net/socket.c:2943)
     __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)
    
    [1]:
    BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)
    stack guard page: 0000 [#1] PREEMPT SMP KASAN
    CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    Workqueue: events netlink_sock_destruct_work
    RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)
    Code: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff
    RSP: 0018:ffffc9000d980000 EFLAGS: 00010293
    RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3
    RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358
    RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000
    R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68
    FS:  0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0
    PKRU: 55555554
    Call Trace:
     <#DF>
     </#DF>
     <TASK>
     fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
     fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
     ...
     fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
     fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
     netlink_sock_destruct (net/netlink/af_netlink.c:401)
     __sk_destruct (net/core/sock.c:2177 (discriminator 2))
     sk_destruct (net/core/sock.c:2224)
     __sk_free (net/core/sock.c:2235)
     sk_free (net/core/sock.c:2246)
     process_one_work (kernel/workqueue.c:3259)
     worker_thread (kernel/workqueue.c:3329 kernel/workqueue.c:3416)
     kthread (kernel/kthread.c:388)
     ret_from_fork (arch/x86/kernel/process.c:153)
     ret_from_fork_asm (arch/x86/entry/entry_64.S:256)
    Modules linked in:
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: David Ahern <dsahern@kernel.org>
    Link: https://lore.kernel.org/r/20240401211003.25274-1-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
isofs: handle CDs with bad root inode but good Joliet root directory [+ + +]
Author: Alex Henrie <alexhenrie24@gmail.com>
Date:   Wed Feb 7 19:21:32 2024 -0700

    isofs: handle CDs with bad root inode but good Joliet root directory
    
    [ Upstream commit 4243bf80c79211a8ca2795401add9c4a3b1d37ca ]
    
    I have a CD copy of the original Tom Clancy's Ghost Recon game from
    2001. The disc mounts without error on Windows, but on Linux mounting
    fails with the message "isofs_fill_super: get root inode failed". The
    error originates in isofs_read_inode, which returns -EIO because de_len
    is 0. The superblock on this disc appears to be intentionally corrupt as
    a form of copy protection.
    
    When the root inode is unusable, instead of giving up immediately, try
    to continue with the Joliet file table. This fixes the Ghost Recon CD
    and probably other copy-protected CDs too.
    
    Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Message-Id: <20240208022134.451490-1-alexhenrie24@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ixgbe: avoid sleeping allocation in ixgbe_ipsec_vf_add_sa() [+ + +]
Author: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Date:   Tue Mar 5 17:02:02 2024 +0100

    ixgbe: avoid sleeping allocation in ixgbe_ipsec_vf_add_sa()
    
    [ Upstream commit aec806fb4afba5fe80b09e29351379a4292baa43 ]
    
    Change kzalloc() flags used in ixgbe_ipsec_vf_add_sa() to GFP_ATOMIC, to
    avoid sleeping in IRQ context.
    
    Dan Carpenter, with the help of Smatch, has found following issue:
    The patch eda0333ac293: "ixgbe: add VF IPsec management" from Aug 13,
    2018 (linux-next), leads to the following Smatch static checker
    warning: drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c:917 ixgbe_ipsec_vf_add_sa()
            warn: sleeping in IRQ context
    
    The call tree that Smatch is worried about is:
    ixgbe_msix_other() <- IRQ handler
    -> ixgbe_msg_task()
       -> ixgbe_rcv_msg_from_vf()
          -> ixgbe_ipsec_vf_add_sa()
    
    Fixes: eda0333ac293 ("ixgbe: add VF IPsec management")
    Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/intel-wired-lan/db31a0b0-4d9f-4e6b-aed8-88266eb5665c@moroto.mountain
    Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
    Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
    Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
kbuild: dummy-tools: adjust to stricter stackprotector check [+ + +]
Author: Michal Kubecek <mkubecek@suse.cz>
Date:   Sat May 15 12:11:13 2021 +0200

    kbuild: dummy-tools: adjust to stricter stackprotector check
    
    commit c93db682cfb213501881072a9200a48ce1dc3c3f upstream.
    
    Commit 3fb0fdb3bbe7 ("x86/stackprotector/32: Make the canary into a regular
    percpu variable") modified the stackprotector check on 32-bit x86 to check
    if gcc supports using %fs as canary. Adjust dummy-tools gcc script to pass
    this new test by returning "%fs" rather than "%gs" if it detects
    -mstack-protector-guard-reg=fs on command line.
    
    Fixes: 3fb0fdb3bbe7 ("x86/stackprotector/32: Make the canary into a regular percpu variable")
    Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1 [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Tue Mar 5 15:12:47 2024 -0700

    kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1
    
    [ Upstream commit 75b5ab134bb5f657ef7979a59106dce0657e8d87 ]
    
    Clang enables -Wenum-enum-conversion and -Wenum-compare-conditional
    under -Wenum-conversion. A recent change in Clang strengthened these
    warnings and they appear frequently in common builds, primarily due to
    several instances in common headers but there are quite a few drivers
    that have individual instances as well.
    
      include/linux/vmstat.h:508:43: warning: arithmetic between different enumeration types ('enum zone_stat_item' and 'enum numa_stat_item') [-Wenum-enum-conversion]
        508 |         return vmstat_text[NR_VM_ZONE_STAT_ITEMS +
            |                            ~~~~~~~~~~~~~~~~~~~~~ ^
        509 |                            item];
            |                            ~~~~
    
      drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:955:24: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional]
        955 |                 flags |= is_new_rate ? IWL_MAC_BEACON_CCK
            |                                      ^ ~~~~~~~~~~~~~~~~~~
        956 |                           : IWL_MAC_BEACON_CCK_V1;
            |                             ~~~~~~~~~~~~~~~~~~~~~
      drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c:1120:21: warning: conditional expression between different enumeration types ('enum iwl_mac_beacon_flags' and 'enum iwl_mac_beacon_flags_v1') [-Wenum-compare-conditional]
       1120 |                                                0) > 10 ?
            |                                                        ^
       1121 |                         IWL_MAC_BEACON_FILS :
            |                         ~~~~~~~~~~~~~~~~~~~
       1122 |                         IWL_MAC_BEACON_FILS_V1;
            |                         ~~~~~~~~~~~~~~~~~~~~~~
    
    Doing arithmetic between or returning two different types of enums could
    be a bug, so each of the instance of the warning needs to be evaluated.
    Unfortunately, as mentioned above, there are many instances of this
    warning in many different configurations, which can break the build when
    CONFIG_WERROR is enabled.
    
    To avoid introducing new instances of the warnings while cleaning up the
    disruption for the majority of users, disable these warnings for the
    default build while leaving them on for W=1 builds.
    
    Cc: stable@vger.kernel.org
    Closes: https://github.com/ClangBuiltLinux/linux/issues/2002
    Link: https://github.com/llvm/llvm-project/commit/8c2ae42b3e1c6aa7c18f873edcebff7c0b45a37e
    Acked-by: Yonghong Song <yonghong.song@linux.dev>
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ktest: force $buildonly = 1 for 'make_warnings_file' test type [+ + +]
Author: Ricardo B. Marliere <ricardo@marliere.net>
Date:   Fri Mar 15 12:28:08 2024 -0300

    ktest: force $buildonly = 1 for 'make_warnings_file' test type
    
    [ Upstream commit 07283c1873a4d0eaa0e822536881bfdaea853910 ]
    
    The test type "make_warnings_file" should have no mandatory configuration
    parameters other than the ones required by the "build" test type, because
    its purpose is to create a file with build warnings that may or may not be
    used by other subsequent tests. Currently, the only way to use it as a
    stand-alone test is by setting POWER_CYCLE, CONSOLE, SSH_USER,
    BUILD_TARGET, TARGET_IMAGE, REBOOT_TYPE and GRUB_MENU.
    
    Link: https://lkml.kernel.org/r/20240315-ktest-v2-1-c5c20a75f6a3@marliere.net
    
    Cc: John Hawley <warthog9@eaglescrag.net>
    Signed-off-by: Ricardo B. Marliere <ricardo@marliere.net>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
KVM/VMX: Move VERW closer to VMentry for MDS mitigation [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Mar 12 15:41:02 2024 -0700

    KVM/VMX: Move VERW closer to VMentry for MDS mitigation
    
    commit 43fb862de8f628c5db5e96831c915b9aebf62d33 upstream.
    
    During VMentry VERW is executed to mitigate MDS. After VERW, any memory
    access like register push onto stack may put host data in MDS affected
    CPU buffers. A guest can then use MDS to sample host data.
    
    Although likelihood of secrets surviving in registers at current VERW
    callsite is less, but it can't be ruled out. Harden the MDS mitigation
    by moving the VERW mitigation late in VMentry path.
    
    Note that VERW for MMIO Stale Data mitigation is unchanged because of
    the complexity of per-guest conditional VERW which is not easy to handle
    that late in asm with no GPRs available. If the CPU is also affected by
    MDS, VERW is unconditionally executed late in asm regardless of guest
    having MMIO access.
    
      [ pawan: conflict resolved in backport ]
    
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Acked-by: Sean Christopherson <seanjc@google.com>
    Link: https://lore.kernel.org/all/20240213-delay-verw-v8-6-a6216d83edb7%40linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

KVM/VMX: Use BT+JNC, i.e. EFLAGS.CF to select VMRESUME vs. VMLAUNCH [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Mar 12 15:40:56 2024 -0700

    KVM/VMX: Use BT+JNC, i.e. EFLAGS.CF to select VMRESUME vs. VMLAUNCH
    
    From: Sean Christopherson <seanjc@google.com>
    
    commit 706a189dcf74d3b3f955e9384785e726ed6c7c80 upstream.
    
    Use EFLAGS.CF instead of EFLAGS.ZF to track whether to use VMRESUME versus
    VMLAUNCH.  Freeing up EFLAGS.ZF will allow doing VERW, which clobbers ZF,
    for MDS mitigations as late as possible without needing to duplicate VERW
    for both paths.
    
      [ pawan: resolved merge conflict in __vmx_vcpu_run in backport. ]
    
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
    Link: https://lore.kernel.org/all/20240213-delay-verw-v8-5-a6216d83edb7%40linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KVM/x86: Export RFDS_NO and RFDS_CLEAR to guests [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Mar 12 15:41:24 2024 -0700

    KVM/x86: Export RFDS_NO and RFDS_CLEAR to guests
    
    commit 2a0180129d726a4b953232175857d442651b55a0 upstream.
    
    Mitigation for RFDS requires RFDS_CLEAR capability which is enumerated
    by MSR_IA32_ARCH_CAPABILITIES bit 27. If the host has it set, export it
    to guests so that they can deploy the mitigation.
    
    RFDS_NO indicates that the system is not vulnerable to RFDS, export it
    to guests so that they don't deploy the mitigation unnecessarily. When
    the host is not affected by X86_BUG_RFDS, but has RFDS_NO=0, synthesize
    RFDS_NO to the guest.
    
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
KVM: Always flush async #PF workqueue when vCPU is being destroyed [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Tue Jan 9 17:15:30 2024 -0800

    KVM: Always flush async #PF workqueue when vCPU is being destroyed
    
    [ Upstream commit 3d75b8aa5c29058a512db29da7cbee8052724157 ]
    
    Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its
    completion queue, e.g. when a VM and all its vCPUs is being destroyed.
    KVM must ensure that none of its workqueue callbacks is running when the
    last reference to the KVM _module_ is put.  Gifting a reference to the
    associated VM prevents the workqueue callback from dereferencing freed
    vCPU/VM memory, but does not prevent the KVM module from being unloaded
    before the callback completes.
    
    Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from
    async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will
    result in deadlock.  async_pf_execute() can't return until kvm_put_kvm()
    finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
    
     WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]
     Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass
     CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
     Workqueue: events async_pf_execute [kvm]
     RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]
     Call Trace:
      <TASK>
      async_pf_execute+0x198/0x260 [kvm]
      process_one_work+0x145/0x2d0
      worker_thread+0x27e/0x3a0
      kthread+0xba/0xe0
      ret_from_fork+0x2d/0x50
      ret_from_fork_asm+0x11/0x20
      </TASK>
     ---[ end trace 0000000000000000 ]---
     INFO: task kworker/8:1:251 blocked for more than 120 seconds.
           Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
     "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
     task:kworker/8:1     state:D stack:0     pid:251   ppid:2      flags:0x00004000
     Workqueue: events async_pf_execute [kvm]
     Call Trace:
      <TASK>
      __schedule+0x33f/0xa40
      schedule+0x53/0xc0
      schedule_timeout+0x12a/0x140
      __wait_for_common+0x8d/0x1d0
      __flush_work.isra.0+0x19f/0x2c0
      kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]
      kvm_arch_destroy_vm+0x78/0x1b0 [kvm]
      kvm_put_kvm+0x1c1/0x320 [kvm]
      async_pf_execute+0x198/0x260 [kvm]
      process_one_work+0x145/0x2d0
      worker_thread+0x27e/0x3a0
      kthread+0xba/0xe0
      ret_from_fork+0x2d/0x50
      ret_from_fork_asm+0x11/0x20
      </TASK>
    
    If kvm_clear_async_pf_completion_queue() actually flushes the workqueue,
    then there's no need to gift async_pf_execute() a reference because all
    invocations of async_pf_execute() will be forced to complete before the
    vCPU and its VM are destroyed/freed.  And that in turn fixes the module
    unloading bug as __fput() won't do module_put() on the last vCPU reference
    until the vCPU has been freed, e.g. if closing the vCPU file also puts the
    last reference to the KVM module.
    
    Note that kvm_check_async_pf_completion() may also take the work item off
    the completion queue and so also needs to flush the work queue, as the
    work will not be seen by kvm_clear_async_pf_completion_queue().  Waiting
    on the workqueue could theoretically delay a vCPU due to waiting for the
    work to complete, but that's a very, very small chance, and likely a very
    small delay.  kvm_arch_async_page_present_queued() unconditionally makes a
    new request, i.e. will effectively delay entering the guest, so the
    remaining work is really just:
    
            trace_kvm_async_pf_completed(addr, cr2_or_gpa);
    
            __kvm_vcpu_wake_up(vcpu);
    
            mmput(mm);
    
    and mmput() can't drop the last reference to the page tables if the vCPU is
    still alive, i.e. the vCPU won't get stuck tearing down page tables.
    
    Add a helper to do the flushing, specifically to deal with "wakeup all"
    work items, as they aren't actually work items, i.e. are never placed in a
    workqueue.  Trying to flush a bogus workqueue entry rightly makes
    __flush_work() complain (kudos to whoever added that sanity check).
    
    Note, commit 5f6de5cbebee ("KVM: Prevent module exit until all VMs are
    freed") *tried* to fix the module refcounting issue by having VMs grab a
    reference to the module, but that only made the bug slightly harder to hit
    as it gave async_pf_execute() a bit more time to complete before the KVM
    module could be unloaded.
    
    Fixes: af585b921e5d ("KVM: Halt vcpu if page it tries to access is swapped out")
    Cc: stable@vger.kernel.org
    Cc: David Matlack <dmatlack@google.com>
    Reviewed-by: Xu Yilun <yilun.xu@intel.com>
    Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
    Link: https://lore.kernel.org/r/20240110011533.503302-2-seanjc@google.com
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region() [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Fri Feb 16 17:34:30 2024 -0800

    KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region()
    
    commit 5ef1d8c1ddbf696e47b226e11888eaf8d9e8e807 upstream.
    
    Do the cache flush of converted pages in svm_register_enc_region() before
    dropping kvm->lock to fix use-after-free issues where region and/or its
    array of pages could be freed by a different task, e.g. if userspace has
    __unregister_enc_region_locked() already queued up for the region.
    
    Note, the "obvious" alternative of using local variables doesn't fully
    resolve the bug, as region->pages is also dynamically allocated.  I.e. the
    region structure itself would be fine, but region->pages could be freed.
    
    Flushing multiple pages under kvm->lock is unfortunate, but the entire
    flow is a rare slow path, and the manual flush is only needed on CPUs that
    lack coherency for encrypted memory.
    
    Fixes: 19a23da53932 ("Fix unsynchronized access to sev members through svm_register_enc_region")
    Reported-by: Gabe Kirkpatrick <gkirkpatrick@google.com>
    Cc: Josh Eads <josheads@google.com>
    Cc: Peter Gonda <pgonda@google.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Message-Id: <20240217013430.2079561-1-seanjc@google.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
libperf evlist: Avoid out-of-bounds access [+ + +]
Author: Ian Rogers <irogers@google.com>
Date:   Wed Feb 28 23:07:57 2024 -0800

    libperf evlist: Avoid out-of-bounds access
    
    [ Upstream commit 1947b92464c3268381604bbe2ac977a3fd78192f ]
    
    Parallel testing appears to show a race between allocating and setting
    evsel ids. As there is a bounds check on the xyarray it yields a segv
    like:
    
    ```
    AddressSanitizer:DEADLYSIGNAL
    
    =================================================================
    
    ==484408==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010
    
    ==484408==The signal is caused by a WRITE memory access.
    
    ==484408==Hint: address points to the zero page.
    
        #0 0x55cef5d4eff4 in perf_evlist__id_hash tools/lib/perf/evlist.c:256
        #1 0x55cef5d4f132 in perf_evlist__id_add tools/lib/perf/evlist.c:274
        #2 0x55cef5d4f545 in perf_evlist__id_add_fd tools/lib/perf/evlist.c:315
        #3 0x55cef5a1923f in store_evsel_ids util/evsel.c:3130
        #4 0x55cef5a19400 in evsel__store_ids util/evsel.c:3147
        #5 0x55cef5888204 in __run_perf_stat tools/perf/builtin-stat.c:832
        #6 0x55cef5888c06 in run_perf_stat tools/perf/builtin-stat.c:960
        #7 0x55cef58932db in cmd_stat tools/perf/builtin-stat.c:2878
    ...
    ```
    
    Avoid this crash by early exiting the perf_evlist__id_add_fd and
    perf_evlist__id_add is the access is out-of-bounds.
    
    Signed-off-by: Ian Rogers <irogers@google.com>
    Cc: Yang Jihong <yangjihong1@huawei.com>
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Link: https://lore.kernel.org/r/20240229070757.796244-1-irogers@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Linux: Linux 5.10.215 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Apr 13 12:59:59 2024 +0200

    Linux 5.10.215
    
    Link: https://lore.kernel.org/r/20240411095435.633465671@linuxfoundation.org
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mac802154: fix llsec key resources release in mac802154_llsec_key_del [+ + +]
Author: Fedor Pchelkin <pchelkin@ispras.ru>
Date:   Wed Feb 28 19:38:39 2024 +0300

    mac802154: fix llsec key resources release in mac802154_llsec_key_del
    
    [ Upstream commit e8a1e58345cf40b7b272e08ac7b32328b2543e40 ]
    
    mac802154_llsec_key_del() can free resources of a key directly without
    following the RCU rules for waiting before the end of a grace period. This
    may lead to use-after-free in case llsec_lookup_key() is traversing the
    list of keys in parallel with a key deletion:
    
    refcount_t: addition on 0; use-after-free.
    WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0
    Modules linked in:
    CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
    RIP: 0010:refcount_warn_saturate+0x162/0x2a0
    Call Trace:
     <TASK>
     llsec_lookup_key.isra.0+0x890/0x9e0
     mac802154_llsec_encrypt+0x30c/0x9c0
     ieee802154_subif_start_xmit+0x24/0x1e0
     dev_hard_start_xmit+0x13e/0x690
     sch_direct_xmit+0x2ae/0xbc0
     __dev_queue_xmit+0x11dd/0x3c20
     dgram_sendmsg+0x90b/0xd60
     __sys_sendto+0x466/0x4c0
     __x64_sys_sendto+0xe0/0x1c0
     do_syscall_64+0x45/0xf0
     entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    Also, ieee802154_llsec_key_entry structures are not freed by
    mac802154_llsec_key_del():
    
    unreferenced object 0xffff8880613b6980 (size 64):
      comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s)
      hex dump (first 32 bytes):
        78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de  x.......".......
        00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00  ................
      backtrace:
        [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0
        [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0
        [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0
        [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80
        [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0
        [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0
        [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0
        [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440
        [<ffffffff86ff1d88>] genl_rcv+0x28/0x40
        [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820
        [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60
        [<ffffffff86b91b35>] ____sys_sendmsg+0xac5/0xca0
        [<ffffffff86b9c3dd>] ___sys_sendmsg+0x11d/0x1c0
        [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0
        [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0
        [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
    
    Handle the proper resource release in the RCU callback function
    mac802154_llsec_key_del_rcu().
    
    Note that if llsec_lookup_key() finds a key, it gets a refcount via
    llsec_key_get() and locally copies key id from key_entry (which is a
    list element). So it's safe to call llsec_key_put() and free the list
    entry after the RCU grace period elapses.
    
    Found by Linux Verification Center (linuxtesting.org).
    
    Fixes: 5d637d5aabd8 ("mac802154: add llsec structures and mutators")
    Cc: stable@vger.kernel.org
    Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
    Acked-by: Alexander Aring <aahringo@redhat.com>
    Message-ID: <20240228163840.6667-1-pchelkin@ispras.ru>
    Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
media: sta2x11: fix irq handler cast [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Feb 13 10:54:47 2024 +0100

    media: sta2x11: fix irq handler cast
    
    [ Upstream commit 3de49ae81c3a0f83a554ecbce4c08e019f30168e ]
    
    clang-16 warns about casting incompatible function pointers:
    
    drivers/media/pci/sta2x11/sta2x11_vip.c:1057:6: error: cast from 'irqreturn_t (*)(int, struct sta2x11_vip *)' (aka 'enum irqreturn (*)(int, struct sta2x11_vip *)') to 'irq_handler_t' (aka 'enum irqreturn (*)(int, void *)') converts to incompatible function type [-Werror,-Wcast-function-type-strict]
    
    Change the prototype of the irq handler to the regular version with a
    local variable to adjust the argument type.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    [hverkuil: update argument documentation]
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: staging: ipu3-imgu: Set fields before media_entity_pads_init() [+ + +]
Author: Hidenori Kobayashi <hidenorik@chromium.org>
Date:   Tue Jan 9 17:09:09 2024 +0900

    media: staging: ipu3-imgu: Set fields before media_entity_pads_init()
    
    [ Upstream commit 87318b7092670d4086bfec115a0280a60c51c2dd ]
    
    The imgu driver fails to probe with the following message because it
    does not set the pad's flags before calling media_entity_pads_init().
    
    [   14.596315] ipu3-imgu 0000:00:05.0: failed initialize subdev media entity (-22)
    [   14.596322] ipu3-imgu 0000:00:05.0: failed to register subdev0 ret (-22)
    [   14.596327] ipu3-imgu 0000:00:05.0: failed to register pipes (-22)
    [   14.596331] ipu3-imgu 0000:00:05.0: failed to create V4L2 devices (-22)
    
    Fix the initialization order so that the driver probe succeeds. The ops
    initialization is also moved together for readability.
    
    Fixes: a0ca1627b450 ("media: staging/intel-ipu3: Add v4l2 driver based on media framework")
    Cc: <stable@vger.kernel.org> # 6.7
    Cc: Dan Carpenter <dan.carpenter@linaro.org>
    Signed-off-by: Hidenori Kobayashi <hidenorik@chromium.org>
    Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

media: xc4000: Fix atomicity violation in xc4000_get_frequency [+ + +]
Author: Gui-Dong Han <2045gemini@gmail.com>
Date:   Fri Dec 22 13:50:30 2023 +0800

    media: xc4000: Fix atomicity violation in xc4000_get_frequency
    
    [ Upstream commit 36d503ad547d1c75758a6fcdbec2806f1b6aeb41 ]
    
    In xc4000_get_frequency():
            *freq = priv->freq_hz + priv->freq_offset;
    The code accesses priv->freq_hz and priv->freq_offset without holding any
    lock.
    
    In xc4000_set_params():
            // Code that updates priv->freq_hz and priv->freq_offset
            ...
    
    xc4000_get_frequency() and xc4000_set_params() may execute concurrently,
    risking inconsistent reads of priv->freq_hz and priv->freq_offset. Since
    these related data may update during reading, it can result in incorrect
    frequency calculation, leading to atomicity violations.
    
    This possible bug is found by an experimental static analysis tool
    developed by our team, BassCheck[1]. 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 our tool analyzes the source code of
    Linux 6.2.
    
    To address this issue, it is proposed to add a mutex lock pair in
    xc4000_get_frequency() to ensure atomicity. With this patch applied, our
    tool no longer reports the possible bug, with the kernel configuration
    allyesconfig for x86_64. Due to the lack of associated hardware, we cannot
    test the patch in runtime testing, and just verify it according to the
    code logic.
    
    [1] https://sites.google.com/view/basscheck/
    
    Fixes: 4c07e32884ab ("[media] xc4000: Fix get_frequency()")
    Cc: stable@vger.kernel.org
    Reported-by: BassCheck <bass@buaa.edu.cn>
    Signed-off-by: Gui-Dong Han <2045gemini@gmail.com>
    Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mei: me: add arrow lake point H DID [+ + +]
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Sun Feb 11 12:39:12 2024 +0200

    mei: me: add arrow lake point H DID
    
    commit 8436f25802ec028ac7254990893f3e01926d9b79 upstream.
    
    Add Arrow Lake H device id.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Link: https://lore.kernel.org/r/20240211103912.117105-2-tomas.winkler@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: me: add arrow lake point S DID [+ + +]
Author: Alexander Usyskin <alexander.usyskin@intel.com>
Date:   Sun Feb 11 12:39:11 2024 +0200

    mei: me: add arrow lake point S DID
    
    commit 7a9b9012043e126f6d6f4683e67409312d1b707b upstream.
    
    Add Arrow Lake S device id.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
    Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
    Link: https://lore.kernel.org/r/20240211103912.117105-1-tomas.winkler@intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
memtest: use {READ,WRITE}_ONCE in memory scanning [+ + +]
Author: Qiang Zhang <qiang4.zhang@intel.com>
Date:   Tue Mar 12 16:04:23 2024 +0800

    memtest: use {READ,WRITE}_ONCE in memory scanning
    
    [ Upstream commit 82634d7e24271698e50a3ec811e5f50de790a65f ]
    
    memtest failed to find bad memory when compiled with clang.  So use
    {WRITE,READ}_ONCE to access memory to avoid compiler over optimization.
    
    Link: https://lkml.kernel.org/r/20240312080422.691222-1-qiang4.zhang@intel.com
    Signed-off-by: Qiang Zhang <qiang4.zhang@intel.com>
    Cc: Bill Wendling <morbo@google.com>
    Cc: Justin Stitt <justinstitt@google.com>
    Cc: Nathan Chancellor <nathan@kernel.org>
    Cc: Nick Desaulniers <ndesaulniers@google.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mm, vmscan: prevent infinite loop for costly GFP_NOIO | __GFP_RETRY_MAYFAIL allocations [+ + +]
Author: Vlastimil Babka <vbabka@suse.cz>
Date:   Wed Feb 21 12:43:58 2024 +0100

    mm, vmscan: prevent infinite loop for costly GFP_NOIO | __GFP_RETRY_MAYFAIL allocations
    
    commit 803de9000f334b771afacb6ff3e78622916668b0 upstream.
    
    Sven reports an infinite loop in __alloc_pages_slowpath() for costly order
    __GFP_RETRY_MAYFAIL allocations that are also GFP_NOIO.  Such combination
    can happen in a suspend/resume context where a GFP_KERNEL allocation can
    have __GFP_IO masked out via gfp_allowed_mask.
    
    Quoting Sven:
    
    1. try to do a "costly" allocation (order > PAGE_ALLOC_COSTLY_ORDER)
       with __GFP_RETRY_MAYFAIL set.
    
    2. page alloc's __alloc_pages_slowpath tries to get a page from the
       freelist. This fails because there is nothing free of that costly
       order.
    
    3. page alloc tries to reclaim by calling __alloc_pages_direct_reclaim,
       which bails out because a zone is ready to be compacted; it pretends
       to have made a single page of progress.
    
    4. page alloc tries to compact, but this always bails out early because
       __GFP_IO is not set (it's not passed by the snd allocator, and even
       if it were, we are suspending so the __GFP_IO flag would be cleared
       anyway).
    
    5. page alloc believes reclaim progress was made (because of the
       pretense in item 3) and so it checks whether it should retry
       compaction. The compaction retry logic thinks it should try again,
       because:
        a) reclaim is needed because of the early bail-out in item 4
        b) a zonelist is suitable for compaction
    
    6. goto 2. indefinite stall.
    
    (end quote)
    
    The immediate root cause is confusing the COMPACT_SKIPPED returned from
    __alloc_pages_direct_compact() (step 4) due to lack of __GFP_IO to be
    indicating a lack of order-0 pages, and in step 5 evaluating that in
    should_compact_retry() as a reason to retry, before incrementing and
    limiting the number of retries.  There are however other places that
    wrongly assume that compaction can happen while we lack __GFP_IO.
    
    To fix this, introduce gfp_compaction_allowed() to abstract the __GFP_IO
    evaluation and switch the open-coded test in try_to_compact_pages() to use
    it.
    
    Also use the new helper in:
    - compaction_ready(), which will make reclaim not bail out in step 3, so
      there's at least one attempt to actually reclaim, even if chances are
      small for a costly order
    - in_reclaim_compaction() which will make should_continue_reclaim()
      return false and we don't over-reclaim unnecessarily
    - in __alloc_pages_slowpath() to set a local variable can_compact,
      which is then used to avoid retrying reclaim/compaction for costly
      allocations (step 5) if we can't compact and also to skip the early
      compaction attempt that we do in some cases
    
    Link: https://lkml.kernel.org/r/20240221114357.13655-2-vbabka@suse.cz
    Fixes: 3250845d0526 ("Revert "mm, oom: prevent premature OOM killer invocation for high order request"")
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Reported-by: Sven van Ashbrook <svenva@chromium.org>
    Closes: https://lore.kernel.org/all/CAG-rBihs_xMKb3wrMO1%2B-%2Bp4fowP9oy1pa_OTkfxBzPUVOZF%2Bg@mail.gmail.com/
    Tested-by: Karthikeyan Ramasubramanian <kramasub@chromium.org>
    Cc: Brian Geffon <bgeffon@google.com>
    Cc: Curtis Malainey <cujomalainey@chromium.org>
    Cc: Jaroslav Kysela <perex@perex.cz>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: Takashi Iwai <tiwai@suse.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/memory-failure: fix an incorrect use of tail pages [+ + +]
Author: Liu Shixin <liushixin2@huawei.com>
Date:   Thu Mar 7 20:48:41 2024 +0800

    mm/memory-failure: fix an incorrect use of tail pages
    
    When backport commit c79c5a0a00a9 to 5.10-stable, there is a mistake change.
    The head page instead of tail page should be passed to try_to_unmap(),
    otherwise unmap will failed as follows.
    
     Memory failure: 0x121c10: failed to unmap page (mapcount=1)
     Memory failure: 0x121c10: recovery action for unmapping failed page: Ignored
    
    Fixes: 70168fdc743b ("mm/memory-failure: check the mapcount of the precise page")
    Signed-off-by: Liu Shixin <liushixin2@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/migrate: set swap entry values of THP tail pages properly. [+ + +]
Author: Zi Yan <ziy@nvidia.com>
Date:   Wed Mar 6 10:51:35 2024 -0500

    mm/migrate: set swap entry values of THP tail pages properly.
    
    The tail pages in a THP can have swap entry information stored in their
    private field. When migrating to a new page, all tail pages of the new
    page need to update ->private to avoid future data corruption.
    
    This fix is stable-only, since after commit 07e09c483cbe ("mm/huge_memory:
    work on folio->swap instead of page->private when splitting folio"),
    subpages of a swapcached THP no longer requires the maintenance.
    
    Adding THPs to the swapcache was introduced in commit
    38d8b4e6bdc87 ("mm, THP, swap: delay splitting THP during swap out"),
    where each subpage of a THP added to the swapcache had its own swapcache
    entry and required the ->private field to point to the correct swapcache
    entry. Later, when THP migration functionality was implemented in commit
    616b8371539a6 ("mm: thp: enable thp migration in generic path"),
    it initially did not handle the subpages of swapcached THPs, failing to
    update their ->private fields or replace the subpage pointers in the
    swapcache. Subsequently, commit e71769ae5260 ("mm: enable thp migration
    for shmem thp") addressed the swapcache update aspect. This patch fixes
    the update of subpage ->private fields.
    
    Closes: https://lore.kernel.org/linux-mm/1707814102-22682-1-git-send-email-quic_charante@quicinc.com/
    Fixes: 616b8371539a ("mm: thp: enable thp migration in generic path")
    Signed-off-by: Zi Yan <ziy@nvidia.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm: swap: fix race between free_swap_and_cache() and swapoff() [+ + +]
Author: Ryan Roberts <ryan.roberts@arm.com>
Date:   Wed Mar 6 14:03:56 2024 +0000

    mm: swap: fix race between free_swap_and_cache() and swapoff()
    
    [ Upstream commit 82b1c07a0af603e3c47b906c8e991dc96f01688e ]
    
    There was previously a theoretical window where swapoff() could run and
    teardown a swap_info_struct while a call to free_swap_and_cache() was
    running in another thread.  This could cause, amongst other bad
    possibilities, swap_page_trans_huge_swapped() (called by
    free_swap_and_cache()) to access the freed memory for swap_map.
    
    This is a theoretical problem and I haven't been able to provoke it from a
    test case.  But there has been agreement based on code review that this is
    possible (see link below).
    
    Fix it by using get_swap_device()/put_swap_device(), which will stall
    swapoff().  There was an extra check in _swap_info_get() to confirm that
    the swap entry was not free.  This isn't present in get_swap_device()
    because it doesn't make sense in general due to the race between getting
    the reference and swapoff.  So I've added an equivalent check directly in
    free_swap_and_cache().
    
    Details of how to provoke one possible issue (thanks to David Hildenbrand
    for deriving this):
    
    --8<-----
    
    __swap_entry_free() might be the last user and result in
    "count == SWAP_HAS_CACHE".
    
    swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.
    
    So the question is: could someone reclaim the folio and turn
    si->inuse_pages==0, before we completed swap_page_trans_huge_swapped().
    
    Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are
    still references by swap entries.
    
    Process 1 still references subpage 0 via swap entry.
    Process 2 still references subpage 1 via swap entry.
    
    Process 1 quits. Calls free_swap_and_cache().
    -> count == SWAP_HAS_CACHE
    [then, preempted in the hypervisor etc.]
    
    Process 2 quits. Calls free_swap_and_cache().
    -> count == SWAP_HAS_CACHE
    
    Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls
    __try_to_reclaim_swap().
    
    __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()->
    put_swap_folio()->free_swap_slot()->swapcache_free_entries()->
    swap_entry_free()->swap_range_free()->
    ...
    WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);
    
    What stops swapoff to succeed after process 2 reclaimed the swap cache
    but before process1 finished its call to swap_page_trans_huge_swapped()?
    
    --8<-----
    
    Link: https://lkml.kernel.org/r/20240306140356.3974886-1-ryan.roberts@arm.com
    Fixes: 7c00bafee87c ("mm/swap: free swap slots in batch")
    Closes: https://lore.kernel.org/linux-mm/65a66eb9-41f8-4790-8db2-0c70ea15979f@redhat.com/
    Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: "Huang, Ying" <ying.huang@intel.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mmc: core: Avoid negative index with array access [+ + +]
Author: Mikko Rapeli <mikko.rapeli@linaro.org>
Date:   Wed Mar 13 15:37:44 2024 +0200

    mmc: core: Avoid negative index with array access
    
    commit cf55a7acd1ed38afe43bba1c8a0935b51d1dc014 upstream.
    
    Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns
    prev_idata = idatas[i - 1], but doesn't check that the iterator i is
    greater than zero. Let's fix this by adding a check.
    
    Fixes: 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu")
    Link: https://lore.kernel.org/all/20231129092535.3278-1-avri.altman@wdc.com/
    Cc: stable@vger.kernel.org
    Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Tested-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Link: https://lore.kernel.org/r/20240313133744.2405325-2-mikko.rapeli@linaro.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: core: Fix switch on gp3 partition [+ + +]
Author: Dominique Martinet <dominique.martinet@atmark-techno.com>
Date:   Wed Mar 6 10:44:38 2024 +0900

    mmc: core: Fix switch on gp3 partition
    
    [ Upstream commit 4af59a8df5ea930038cd3355e822f5eedf4accc1 ]
    
    Commit e7794c14fd73 ("mmc: rpmb: fixes pause retune on all RPMB
    partitions.") added a mask check for 'part_type', but the mask used was
    wrong leading to the code intended for rpmb also being executed for GP3.
    
    On some MMCs (but not all) this would make gp3 partition inaccessible:
    armadillo:~# head -c 1 < /dev/mmcblk2gp3
    head: standard input: I/O error
    armadillo:~# dmesg -c
    [  422.976583] mmc2: running CQE recovery
    [  423.058182] mmc2: running CQE recovery
    [  423.137607] mmc2: running CQE recovery
    [  423.137802] blk_update_request: I/O error, dev mmcblk2gp3, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
    [  423.237125] mmc2: running CQE recovery
    [  423.318206] mmc2: running CQE recovery
    [  423.397680] mmc2: running CQE recovery
    [  423.397837] blk_update_request: I/O error, dev mmcblk2gp3, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
    [  423.408287] Buffer I/O error on dev mmcblk2gp3, logical block 0, async page read
    
    the part_type values of interest here are defined as follow:
    main  0
    boot0 1
    boot1 2
    rpmb  3
    gp0   4
    gp1   5
    gp2   6
    gp3   7
    
    so mask with EXT_CSD_PART_CONFIG_ACC_MASK (7) to correctly identify rpmb
    
    Fixes: e7794c14fd73 ("mmc: rpmb: fixes pause retune on all RPMB partitions.")
    Cc: stable@vger.kernel.org
    Cc: Jorge Ramirez-Ortiz <jorge@foundries.io>
    Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Link: https://lore.kernel.org/r/20240306-mmc-partswitch-v1-1-bf116985d950@codewreck.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

mmc: core: Initialize mmc_blk_ioc_data [+ + +]
Author: Mikko Rapeli <mikko.rapeli@linaro.org>
Date:   Wed Mar 13 15:37:43 2024 +0200

    mmc: core: Initialize mmc_blk_ioc_data
    
    commit 0cdfe5b0bf295c0dee97436a8ed13336933a0211 upstream.
    
    Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") adds
    flags uint to struct mmc_blk_ioc_data, but it does not get initialized for
    RPMB ioctls which now fails.
    
    Let's fix this by always initializing the struct and flags to zero.
    
    Fixes: 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218587
    Link: https://lore.kernel.org/all/20231129092535.3278-1-avri.altman@wdc.com/
    Cc: stable@vger.kernel.org
    Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
    Reviewed-by: Avri Altman <avri.altman@wdc.com>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Tested-by: Francesco Dolcini <francesco.dolcini@toradex.com>
    Link: https://lore.kernel.org/r/20240313133744.2405325-1-mikko.rapeli@linaro.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: tmio: avoid concurrent runs of mmc_request_done() [+ + +]
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Tue Mar 5 11:42:56 2024 +0100

    mmc: tmio: avoid concurrent runs of mmc_request_done()
    
    [ Upstream commit e8d1b41e69d72c62865bebe8f441163ec00b3d44 ]
    
    With the to-be-fixed commit, the reset_work handler cleared 'host->mrq'
    outside of the spinlock protected critical section. That leaves a small
    race window during execution of 'tmio_mmc_reset()' where the done_work
    handler could grab a pointer to the now invalid 'host->mrq'. Both would
    use it to call mmc_request_done() causing problems (see link below).
    
    However, 'host->mrq' cannot simply be cleared earlier inside the
    critical section. That would allow new mrqs to come in asynchronously
    while the actual reset of the controller still needs to be done. So,
    like 'tmio_mmc_set_ios()', an ERR_PTR is used to prevent new mrqs from
    coming in but still avoiding concurrency between work handlers.
    
    Reported-by: Dirk Behme <dirk.behme@de.bosch.com>
    Closes: https://lore.kernel.org/all/20240220061356.3001761-1-dirk.behme@de.bosch.com/
    Fixes: df3ef2d3c92c ("mmc: protect the tmio_mmc driver against a theoretical race")
    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
    Reviewed-by: Dirk Behme <dirk.behme@de.bosch.com>
    Cc: stable@vger.kernel.org # 3.0+
    Link: https://lore.kernel.org/r/20240305104423.3177-2-wsa+renesas@sang-engineering.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
mptcp: don't account accept() of non-MPC client as fallback to TCP [+ + +]
Author: Davide Caratti <dcaratti@redhat.com>
Date:   Fri Mar 29 13:08:52 2024 +0100

    mptcp: don't account accept() of non-MPC client as fallback to TCP
    
    commit 7a1b3490f47e88ec4cbde65f1a77a0f4bc972282 upstream.
    
    Current MPTCP servers increment MPTcpExtMPCapableFallbackACK when they
    accept non-MPC connections. As reported by Christoph, this is "surprising"
    because the counter might become greater than MPTcpExtMPCapableSYNRX.
    
    MPTcpExtMPCapableFallbackACK counter's name suggests it should only be
    incremented when a connection was seen using MPTCP options, then a
    fallback to TCP has been done. Let's do that by incrementing it when
    the subflow context of an inbound MPC connection attempt is dropped.
    Also, update mptcp_connect.sh kselftest, to ensure that the
    above MIB does not increment in case a pure TCP client connects to a
    MPTCP server.
    
    Fixes: fc518953bc9c ("mptcp: add and use MIB counter infrastructure")
    Cc: stable@vger.kernel.org
    Reported-by: Christoph Paasch <cpaasch@apple.com>
    Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/449
    Signed-off-by: Davide Caratti <dcaratti@redhat.com>
    Reviewed-by: Mat Martineau <martineau@kernel.org>
    Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Link: https://lore.kernel.org/r/20240329-upstream-net-20240329-fallback-mib-v1-1-324a8981da48@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mtd: rawnand: meson: fix scrambling mode value in command macro [+ + +]
Author: Arseniy Krasnov <avkrasnov@salutedevices.com>
Date:   Sun Feb 11 00:45:51 2024 +0300

    mtd: rawnand: meson: fix scrambling mode value in command macro
    
    [ Upstream commit ef6f463599e16924cdd02ce5056ab52879dc008c ]
    
    Scrambling mode is enabled by value (1 << 19). NFC_CMD_SCRAMBLER_ENABLE
    is already (1 << 19), so there is no need to shift it again in CMDRWGEN
    macro.
    
    Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
    Cc: <Stable@vger.kernel.org>
    Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20240210214551.441610-1-avkrasnov@salutedevices.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net/rds: fix possible cp null dereference [+ + +]
Author: Mahmoud Adam <mngyadam@amazon.com>
Date:   Tue Mar 26 16:31:33 2024 +0100

    net/rds: fix possible cp null dereference
    
    commit 62fc3357e079a07a22465b9b6ef71bb6ea75ee4b upstream.
    
    cp might be null, calling cp->cp_conn would produce null dereference
    
    [Simon Horman adds:]
    
    Analysis:
    
    * cp is a parameter of __rds_rdma_map and is not reassigned.
    
    * The following call-sites pass a NULL cp argument to __rds_rdma_map()
    
      - rds_get_mr()
      - rds_get_mr_for_dest
    
    * Prior to the code above, the following assumes that cp may be NULL
      (which is indicative, but could itself be unnecessary)
    
            trans_private = rs->rs_transport->get_mr(
                    sg, nents, rs, &mr->r_key, cp ? cp->cp_conn : NULL,
                    args->vec.addr, args->vec.bytes,
                    need_odp ? ODP_ZEROBASED : ODP_NOT_NEEDED);
    
    * The code modified by this patch is guarded by IS_ERR(trans_private),
      where trans_private is assigned as per the previous point in this analysis.
    
      The only implementation of get_mr that I could locate is rds_ib_get_mr()
      which can return an ERR_PTR if the conn (4th) argument is NULL.
    
    * ret is set to PTR_ERR(trans_private).
      rds_ib_get_mr can return ERR_PTR(-ENODEV) if the conn (4th) argument is NULL.
      Thus ret may be -ENODEV in which case the code in question will execute.
    
    Conclusion:
    * cp may be NULL at the point where this patch adds a check;
      this patch does seem to address a possible bug
    
    Fixes: c055fc00c07b ("net/rds: fix WARNING in rds_conn_connect_if_down")
    Cc: stable@vger.kernel.org # v4.19+
    Signed-off-by: Mahmoud Adam <mngyadam@amazon.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240326153132.55580-1-mngyadam@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/sched: act_skbmod: prevent kernel-infoleak [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Wed Apr 3 13:09:08 2024 +0000

    net/sched: act_skbmod: prevent kernel-infoleak
    
    commit d313eb8b77557a6d5855f42d2234bd592c7b50dd upstream.
    
    syzbot found that tcf_skbmod_dump() was copying four bytes
    from kernel stack to user space [1].
    
    The issue here is that 'struct tc_skbmod' has a four bytes hole.
    
    We need to clear the structure before filling fields.
    
    [1]
    BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
     BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
     BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
     BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
     BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
     BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
      instrument_copy_to_user include/linux/instrumented.h:114 [inline]
      copy_to_user_iter lib/iov_iter.c:24 [inline]
      iterate_ubuf include/linux/iov_iter.h:29 [inline]
      iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
      iterate_and_advance include/linux/iov_iter.h:271 [inline]
      _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
      copy_to_iter include/linux/uio.h:196 [inline]
      simple_copy_to_iter net/core/datagram.c:532 [inline]
      __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420
      skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
      skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]
      netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962
      sock_recvmsg_nosec net/socket.c:1046 [inline]
      sock_recvmsg+0x2c4/0x340 net/socket.c:1068
      __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242
      __do_sys_recvfrom net/socket.c:2260 [inline]
      __se_sys_recvfrom net/socket.c:2256 [inline]
      __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256
     do_syscall_64+0xd5/0x1f0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    Uninit was stored to memory at:
      pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253
      netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317
      netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351
      nlmsg_unicast include/net/netlink.h:1144 [inline]
      nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610
      rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741
      rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]
      tcf_add_notify net/sched/act_api.c:2048 [inline]
      tcf_action_add net/sched/act_api.c:2071 [inline]
      tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119
      rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
      netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
      rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
      netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
      netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
      netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:745
      ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
      ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
      __sys_sendmsg net/socket.c:2667 [inline]
      __do_sys_sendmsg net/socket.c:2676 [inline]
      __se_sys_sendmsg net/socket.c:2674 [inline]
      __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
     do_syscall_64+0xd5/0x1f0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    Uninit was stored to memory at:
      __nla_put lib/nlattr.c:1041 [inline]
      nla_put+0x1c6/0x230 lib/nlattr.c:1099
      tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256
      tcf_action_dump_old net/sched/act_api.c:1191 [inline]
      tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
      tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251
      tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628
      tcf_add_notify_msg net/sched/act_api.c:2023 [inline]
      tcf_add_notify net/sched/act_api.c:2042 [inline]
      tcf_action_add net/sched/act_api.c:2071 [inline]
      tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119
      rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595
      netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559
      rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613
      netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
      netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361
      netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905
      sock_sendmsg_nosec net/socket.c:730 [inline]
      __sock_sendmsg+0x30f/0x380 net/socket.c:745
      ____sys_sendmsg+0x877/0xb60 net/socket.c:2584
      ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
      __sys_sendmsg net/socket.c:2667 [inline]
      __do_sys_sendmsg net/socket.c:2676 [inline]
      __se_sys_sendmsg net/socket.c:2674 [inline]
      __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674
     do_syscall_64+0xd5/0x1f0
     entry_SYSCALL_64_after_hwframe+0x6d/0x75
    
    Local variable opt created at:
      tcf_skbmod_dump+0x9d/0xc20 net/sched/act_skbmod.c:244
      tcf_action_dump_old net/sched/act_api.c:1191 [inline]
      tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227
    
    Bytes 188-191 of 248 are uninitialized
    Memory access of size 248 starts at ffff888117697680
    Data copied to user address 00007ffe56d855f0
    
    Fixes: 86da71b57383 ("net_sched: Introduce skbmod action")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Link: https://lore.kernel.org/r/20240403130908.93421-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list() [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Sat Mar 2 10:07:44 2024 +0000

    net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list()
    
    [ Upstream commit 00af2aa93b76b1bade471ad0d0525d4d29ca5cc0 ]
    
    Many syzbot reports show extreme rtnl pressure, and many of them hint
    that smc acquires rtnl in netns creation for no good reason [1]
    
    This patch returns early from smc_pnet_net_init()
    if there is no netdevice yet.
    
    I am not even sure why smc_pnet_create_pnetids_list() even exists,
    because smc_pnet_netdev_event() is also calling
    smc_pnet_add_base_pnetid() when handling NETDEV_UP event.
    
    [1] extract of typical syzbot reports
    
    2 locks held by syz-executor.3/12252:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.4/12253:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.1/12257:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.2/12261:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.0/12265:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.3/12268:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.4/12271:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.1/12274:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    2 locks held by syz-executor.2/12280:
      #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
      #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
    
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Wenjia Zhang <wenjia@linux.ibm.com>
    Cc: Jan Karcher <jaka@linux.ibm.com>
    Cc: "D. Wythe" <alibuda@linux.alibaba.com>
    Cc: Tony Lu <tonylu@linux.alibaba.com>
    Cc: Wen Gu <guwen@linux.alibaba.com>
    Reviewed-by: Wenjia Zhang <wenjia@linux.ibm.com>
    Link: https://lore.kernel.org/r/20240302100744.3868021-1-edumazet@google.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
net: hns3: tracing: fix hclgevf trace event strings [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Wed Mar 13 09:34:54 2024 -0400

    net: hns3: tracing: fix hclgevf trace event strings
    
    [ Upstream commit 3f9952e8d80cca2da3b47ecd5ad9ec16cfd1a649 ]
    
    The __string() and __assign_str() helper macros of the TRACE_EVENT() macro
    are going through some optimizations where only the source string of
    __string() will be used and the __assign_str() source will be ignored and
    later removed.
    
    To make sure that there's no issues, a new check is added between the
    __string() src argument and the __assign_str() src argument that does a
    strcmp() to make sure they are the same string.
    
    The hclgevf trace events have:
    
      __assign_str(devname, &hdev->nic.kinfo.netdev->name);
    
    Which triggers the warning:
    
    hclgevf_trace.h:34:39: error: passing argument 1 of ‘strcmp’ from incompatible pointer type [-Werror=incompatible-pointer-types]
       34 |                 __assign_str(devname, &hdev->nic.kinfo.netdev->name);
     [..]
    arch/x86/include/asm/string_64.h:75:24: note: expected ‘const char *’ but argument is of type ‘char (*)[16]’
       75 | int strcmp(const char *cs, const char *ct);
          |            ~~~~~~~~~~~~^~
    
    Because __assign_str() now has:
    
            WARN_ON_ONCE(__builtin_constant_p(src) ?                \
                         strcmp((src), __data_offsets.dst##_ptr_) : \
                         (src) != __data_offsets.dst##_ptr_);       \
    
    The problem is the '&' on hdev->nic.kinfo.netdev->name. That's because
    that name is:
    
            char                    name[IFNAMSIZ]
    
    Where passing an address '&' of a char array is not compatible with strcmp().
    
    The '&' is not necessary, remove it.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240313093454.3909afe7@gandalf.local.home
    
    Cc: netdev <netdev@vger.kernel.org>
    Cc: Yisen Zhuang <yisen.zhuang@huawei.com>
    Cc: Salil Mehta <salil.mehta@huawei.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Eric Dumazet <edumazet@google.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: Yufeng Mo <moyufeng@huawei.com>
    Cc: Huazhong Tan <tanhuazhong@huawei.com>
    Cc: stable@vger.kernel.org
    Acked-by: Paolo Abeni <pabeni@redhat.com>
    Reviewed-by: Jijie Shao <shaojijie@huawei.com>
    Fixes: d8355240cf8fb ("net: hns3: add trace event support for PF/VF mailbox")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: ll_temac: platform_get_resource replaced by wrong function [+ + +]
Author: Claus Hansen Ries <chr@terma.com>
Date:   Thu Mar 21 13:08:59 2024 +0000

    net: ll_temac: platform_get_resource replaced by wrong function
    
    commit 3a38a829c8bc27d78552c28e582eb1d885d07d11 upstream.
    
    The function platform_get_resource was replaced with
    devm_platform_ioremap_resource_byname and is called using 0 as name.
    
    This eventually ends up in platform_get_resource_byname in the call
    stack, where it causes a null pointer in strcmp.
    
            if (type == resource_type(r) && !strcmp(r->name, name))
    
    It should have been replaced with devm_platform_ioremap_resource.
    
    Fixes: bd69058f50d5 ("net: ll_temac: Use devm_platform_ioremap_resource_byname()")
    Signed-off-by: Claus Hansen Ries <chr@terma.com>
    Cc: stable@vger.kernel.org
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/cca18f9c630a41c18487729770b492bb@terma.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: ravb: Always process TX descriptor ring [+ + +]
Author: Paul Barker <paul.barker.ct@bp.renesas.com>
Date:   Tue Apr 2 15:53:04 2024 +0100

    net: ravb: Always process TX descriptor ring
    
    [ Upstream commit 596a4254915f94c927217fe09c33a6828f33fb25 ]
    
    The TX queue should be serviced each time the poll function is called,
    even if the full RX work budget has been consumed. This prevents
    starvation of the TX queue when RX bandwidth usage is high.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
    Reviewed-by: Sergey Shtylyov <s.shtylyov@omp.ru>
    Link: https://lore.kernel.org/r/20240402145305.82148-1-paul.barker.ct@bp.renesas.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: stmmac: fix rx queue priority assignment [+ + +]
Author: Piotr Wejman <piotrwejman90@gmail.com>
Date:   Mon Apr 1 21:22:39 2024 +0200

    net: stmmac: fix rx queue priority assignment
    
    commit b3da86d432b7cd65b025a11f68613e333d2483db upstream.
    
    The driver should ensure that same priority is not mapped to multiple
    rx queues. From DesignWare Cores Ethernet Quality-of-Service
    Databook, section 17.1.29 MAC_RxQ_Ctrl2:
    "[...]The software must ensure that the content of this field is
    mutually exclusive to the PSRQ fields for other queues, that is,
    the same priority is not mapped to multiple Rx queues[...]"
    
    Previously rx_queue_priority() function was:
    - clearing all priorities from a queue
    - adding new priorities to that queue
    After this patch it will:
    - first assign new priorities to a queue
    - then remove those priorities from all other queues
    - keep other priorities previously assigned to that queue
    
    Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority configuration")
    Fixes: 2142754f8b9c ("net: stmmac: Add MAC related callbacks for XGMAC2")
    Signed-off-by: Piotr Wejman <piotrwejman90@gmail.com>
    Link: https://lore.kernel.org/r/20240401192239.33942-1-piotrwejman90@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netfilter: nf_tables: disallow anonymous set with timeout flag [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Mar 1 00:11:10 2024 +0100

    netfilter: nf_tables: disallow anonymous set with timeout flag
    
    commit 16603605b667b70da974bea8216c93e7db043bf1 upstream.
    
    Anonymous sets are never used with timeout from userspace, reject this.
    Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.
    
    Cc: stable@vger.kernel.org
    Fixes: 761da2935d6e ("netfilter: nf_tables: add set timeout API support")
    Reported-by: lonial con <kongln9170@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: disallow timeout for anonymous sets [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Jun 16 15:22:18 2023 +0200

    netfilter: nf_tables: disallow timeout for anonymous sets
    
    commit e26d3009efda338f19016df4175f354a9bd0a4ab upstream.
    
    Never used from userspace, disallow these parameters.
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    [Keerthana: code surrounding the patch is different
    because nft_set_desc is not present in v4.19-v5.10]
    Signed-off-by: Keerthana K <keerthana.kalyanasundaram@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: discard table flag update with pending basechain deletion [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Apr 8 23:20:42 2024 +0200

    netfilter: nf_tables: discard table flag update with pending basechain deletion
    
    commit 1bc83a019bbe268be3526406245ec28c2458a518 upstream.
    
    Hook unregistration is deferred to the commit phase, same occurs with
    hook updates triggered by the table dormant flag. When both commands are
    combined, this results in deleting a basechain while leaving its hook
    still registered in the core.
    
    Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() [+ + +]
Author: Ziyang Xuan <william.xuanziyang@huawei.com>
Date:   Wed Apr 3 15:22:04 2024 +0800

    netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
    
    commit 24225011d81b471acc0e1e315b7d9905459a6304 upstream.
    
    nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can
    concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().
    And thhere is not any protection when iterate over nf_tables_flowtables
    list in __nft_flowtable_type_get(). Therefore, there is pertential
    data-race of nf_tables_flowtables list entry.
    
    Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list
    in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller
    nft_flowtable_type_get() to protect the entire type query process.
    
    Fixes: 3b49e2e94e6e ("netfilter: nf_tables: add flow table netlink frontend")
    Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: flush pending destroy work before exit_net release [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Tue Apr 2 18:04:36 2024 +0200

    netfilter: nf_tables: flush pending destroy work before exit_net release
    
    commit 24cea9677025e0de419989ecb692acd4bb34cac2 upstream.
    
    Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy
    work before netlink notifier") to address a race between exit_net and
    the destroy workqueue.
    
    The trace below shows an element to be released via destroy workqueue
    while exit_net path (triggered via module removal) has already released
    the set that is used in such transaction.
    
    [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
    [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465
    [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359
    [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
    [ 1360.547984] Call Trace:
    [ 1360.547991]  <TASK>
    [ 1360.547998]  dump_stack_lvl+0x53/0x70
    [ 1360.548014]  print_report+0xc4/0x610
    [ 1360.548026]  ? __virt_addr_valid+0xba/0x160
    [ 1360.548040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
    [ 1360.548054]  ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
    [ 1360.548176]  kasan_report+0xae/0xe0
    [ 1360.548189]  ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
    [ 1360.548312]  nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
    [ 1360.548447]  ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables]
    [ 1360.548577]  ? _raw_spin_unlock_irq+0x18/0x30
    [ 1360.548591]  process_one_work+0x2f1/0x670
    [ 1360.548610]  worker_thread+0x4d3/0x760
    [ 1360.548627]  ? __pfx_worker_thread+0x10/0x10
    [ 1360.548640]  kthread+0x16b/0x1b0
    [ 1360.548653]  ? __pfx_kthread+0x10/0x10
    [ 1360.548665]  ret_from_fork+0x2f/0x50
    [ 1360.548679]  ? __pfx_kthread+0x10/0x10
    [ 1360.548690]  ret_from_fork_asm+0x1a/0x30
    [ 1360.548707]  </TASK>
    
    [ 1360.548719] Allocated by task 192061:
    [ 1360.548726]  kasan_save_stack+0x20/0x40
    [ 1360.548739]  kasan_save_track+0x14/0x30
    [ 1360.548750]  __kasan_kmalloc+0x8f/0xa0
    [ 1360.548760]  __kmalloc_node+0x1f1/0x450
    [ 1360.548771]  nf_tables_newset+0x10c7/0x1b50 [nf_tables]
    [ 1360.548883]  nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink]
    [ 1360.548909]  nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]
    [ 1360.548927]  netlink_unicast+0x367/0x4f0
    [ 1360.548935]  netlink_sendmsg+0x34b/0x610
    [ 1360.548944]  ____sys_sendmsg+0x4d4/0x510
    [ 1360.548953]  ___sys_sendmsg+0xc9/0x120
    [ 1360.548961]  __sys_sendmsg+0xbe/0x140
    [ 1360.548971]  do_syscall_64+0x55/0x120
    [ 1360.548982]  entry_SYSCALL_64_after_hwframe+0x55/0x5d
    
    [ 1360.548994] Freed by task 192222:
    [ 1360.548999]  kasan_save_stack+0x20/0x40
    [ 1360.549009]  kasan_save_track+0x14/0x30
    [ 1360.549019]  kasan_save_free_info+0x3b/0x60
    [ 1360.549028]  poison_slab_object+0x100/0x180
    [ 1360.549036]  __kasan_slab_free+0x14/0x30
    [ 1360.549042]  kfree+0xb6/0x260
    [ 1360.549049]  __nft_release_table+0x473/0x6a0 [nf_tables]
    [ 1360.549131]  nf_tables_exit_net+0x170/0x240 [nf_tables]
    [ 1360.549221]  ops_exit_list+0x50/0xa0
    [ 1360.549229]  free_exit_list+0x101/0x140
    [ 1360.549236]  unregister_pernet_operations+0x107/0x160
    [ 1360.549245]  unregister_pernet_subsys+0x1c/0x30
    [ 1360.549254]  nf_tables_module_exit+0x43/0x80 [nf_tables]
    [ 1360.549345]  __do_sys_delete_module+0x253/0x370
    [ 1360.549352]  do_syscall_64+0x55/0x120
    [ 1360.549360]  entry_SYSCALL_64_after_hwframe+0x55/0x5d
    
    (gdb) list *__nft_release_table+0x473
    0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).
    11349           list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) {
    11350                   list_del(&flowtable->list);
    11351                   nft_use_dec(&table->use);
    11352                   nf_tables_flowtable_destroy(flowtable);
    11353           }
    11354           list_for_each_entry_safe(set, ns, &table->sets, list) {
    11355                   list_del(&set->list);
    11356                   nft_use_dec(&table->use);
    11357                   if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT))
    11358                           nft_map_deactivate(&ctx, set);
    (gdb)
    
    [ 1360.549372] Last potentially related work creation:
    [ 1360.549376]  kasan_save_stack+0x20/0x40
    [ 1360.549384]  __kasan_record_aux_stack+0x9b/0xb0
    [ 1360.549392]  __queue_work+0x3fb/0x780
    [ 1360.549399]  queue_work_on+0x4f/0x60
    [ 1360.549407]  nft_rhash_remove+0x33b/0x340 [nf_tables]
    [ 1360.549516]  nf_tables_commit+0x1c6a/0x2620 [nf_tables]
    [ 1360.549625]  nfnetlink_rcv_batch+0x728/0xdc0 [nfnetlink]
    [ 1360.549647]  nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]
    [ 1360.549671]  netlink_unicast+0x367/0x4f0
    [ 1360.549680]  netlink_sendmsg+0x34b/0x610
    [ 1360.549690]  ____sys_sendmsg+0x4d4/0x510
    [ 1360.549697]  ___sys_sendmsg+0xc9/0x120
    [ 1360.549706]  __sys_sendmsg+0xbe/0x140
    [ 1360.549715]  do_syscall_64+0x55/0x120
    [ 1360.549725]  entry_SYSCALL_64_after_hwframe+0x55/0x5d
    
    Fixes: 0935d5588400 ("netfilter: nf_tables: asynchronous release")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Mar 4 14:22:12 2024 +0100

    netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout
    
    commit 552705a3650bbf46a22b1adedc1b04181490fc36 upstream.
    
    While the rhashtable set gc runs asynchronously, a race allows it to
    collect elements from anonymous sets with timeouts while it is being
    released from the commit path.
    
    Mingi Cho originally reported this issue in a different path in 6.1.x
    with a pipapo set with low timeouts which is not possible upstream since
    7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set
    element timeout").
    
    Fix this by setting on the dead flag for anonymous sets to skip async gc
    in this case.
    
    According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on
    transaction abort"), Florian plans to accelerate abort path by releasing
    objects via workqueue, therefore, this sets on the dead flag for abort
    path too.
    
    Cc: stable@vger.kernel.org
    Fixes: 5f68718b34a5 ("netfilter: nf_tables: GC transaction API to avoid race with control plane")
    Reported-by: Mingi Cho <mgcho.minic@gmail.com>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: reject constant set with timeout [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Mar 1 01:04:11 2024 +0100

    netfilter: nf_tables: reject constant set with timeout
    
    commit 5f4fc4bd5cddb4770ab120ce44f02695c4505562 upstream.
    
    This set combination is weird: it allows for elements to be
    added/deleted, but once bound to the rule it cannot be updated anymore.
    Eventually, all elements expire, leading to an empty set which cannot
    be updated anymore. Reject this flags combination.
    
    Cc: stable@vger.kernel.org
    Fixes: 761da2935d6e ("netfilter: nf_tables: add set timeout API support")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: reject new basechain after table flag update [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Apr 1 00:33:02 2024 +0200

    netfilter: nf_tables: reject new basechain after table flag update
    
    commit 994209ddf4f430946f6247616b2e33d179243769 upstream.
    
    When dormant flag is toggled, hooks are disabled in the commit phase by
    iterating over current chains in table (existing and new).
    
    The following configuration allows for an inconsistent state:
    
      add table x
      add chain x y { type filter hook input priority 0; }
      add table x { flags dormant; }
      add chain x w { type filter hook input priority 1; }
    
    which triggers the following warning when trying to unregister chain w
    which is already unregistered.
    
    [  127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50                                                                     1 __nf_unregister_net_hook+0x21a/0x260
    [...]
    [  127.322519] Call Trace:
    [  127.322521]  <TASK>
    [  127.322524]  ? __warn+0x9f/0x1a0
    [  127.322531]  ? __nf_unregister_net_hook+0x21a/0x260
    [  127.322537]  ? report_bug+0x1b1/0x1e0
    [  127.322545]  ? handle_bug+0x3c/0x70
    [  127.322552]  ? exc_invalid_op+0x17/0x40
    [  127.322556]  ? asm_exc_invalid_op+0x1a/0x20
    [  127.322563]  ? kasan_save_free_info+0x3b/0x60
    [  127.322570]  ? __nf_unregister_net_hook+0x6a/0x260
    [  127.322577]  ? __nf_unregister_net_hook+0x21a/0x260
    [  127.322583]  ? __nf_unregister_net_hook+0x6a/0x260
    [  127.322590]  ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables]
    [  127.322655]  nft_table_disable+0x75/0xf0 [nf_tables]
    [  127.322717]  nf_tables_commit+0x2571/0x2620 [nf_tables]
    
    Fixes: 179d9ba5559a ("netfilter: nf_tables: fix table flag updates")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

netfilter: nf_tables: release batch on table validation from abort path [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Apr 8 23:20:40 2024 +0200

    netfilter: nf_tables: release batch on table validation from abort path
    
    commit a45e6889575c2067d3c0212b6bc1022891e65b91 upstream.
    
    Unlike early commit path stage which triggers a call to abort, an
    explicit release of the batch is required on abort, otherwise mutex is
    released and commit_list remains in place.
    
    Add WARN_ON_ONCE to ensure commit_list is empty from the abort path
    before releasing the mutex.
    
    After this patch, commit_list is always assumed to be empty before
    grabbing the mutex, therefore
    
      03c1f1ef1584 ("netfilter: Cleanup nft_net->module_list from nf_tables_exit_net()")
    
    only needs to release the pending modules for registration.
    
    Cc: stable@vger.kernel.org
    Fixes: c0391b6ab810 ("netfilter: nf_tables: missing validation from the abort path")
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Apr 8 23:20:41 2024 +0200

    netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path
    
    commit 0d459e2ffb541841714839e8228b845458ed3b27 upstream.
    
    The commit mutex should not be released during the critical section
    between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC
    worker could collect expired objects and get the released commit lock
    within the same GC sequence.
    
    nf_tables_module_autoload() temporarily releases the mutex to load
    module dependencies, then it goes back to replay the transaction again.
    Move it at the end of the abort phase after nft_gc_seq_end() is called.
    
    Cc: stable@vger.kernel.org
    Fixes: 720344340fb9 ("netfilter: nf_tables: GC transaction race with abort path")
    Reported-by: Kuan-Ting Chen <hexrabbit@devco.re>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

netfilter: validate user input for expected length [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Thu Apr 4 12:20:51 2024 +0000

    netfilter: validate user input for expected length
    
    commit 0c83842df40f86e529db6842231154772c20edcc upstream.
    
    I got multiple syzbot reports showing old bugs exposed
    by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc
    in cgroup/{s,g}etsockopt")
    
    setsockopt() @optlen argument should be taken into account
    before copying data.
    
     BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
     BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
     BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
     BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
    Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
    
    CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
    Call Trace:
     <TASK>
      __dump_stack lib/dump_stack.c:88 [inline]
      dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
      print_address_description mm/kasan/report.c:377 [inline]
      print_report+0x169/0x550 mm/kasan/report.c:488
      kasan_report+0x143/0x180 mm/kasan/report.c:601
      kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
      __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105
      copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
      copy_from_sockptr include/linux/sockptr.h:55 [inline]
      do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
      do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
      nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101
      do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
      __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
      __do_sys_setsockopt net/socket.c:2343 [inline]
      __se_sys_setsockopt net/socket.c:2340 [inline]
      __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
     do_syscall_64+0xfb/0x240
     entry_SYSCALL_64_after_hwframe+0x72/0x7a
    RIP: 0033:0x7fd22067dde9
    Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
    RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
    RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9
    RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
    RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000
    R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8
     </TASK>
    
    Allocated by task 7238:
      kasan_save_stack mm/kasan/common.c:47 [inline]
      kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
      poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
      __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
      kasan_kmalloc include/linux/kasan.h:211 [inline]
      __do_kmalloc_node mm/slub.c:4069 [inline]
      __kmalloc_noprof+0x200/0x410 mm/slub.c:4082
      kmalloc_noprof include/linux/slab.h:664 [inline]
      __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869
      do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
      __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
      __do_sys_setsockopt net/socket.c:2343 [inline]
      __se_sys_setsockopt net/socket.c:2340 [inline]
      __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
     do_syscall_64+0xfb/0x240
     entry_SYSCALL_64_after_hwframe+0x72/0x7a
    
    The buggy address belongs to the object at ffff88802cd73da0
     which belongs to the cache kmalloc-8 of size 8
    The buggy address is located 0 bytes inside of
     allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
    
    The buggy address belongs to the physical page:
    page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73
    flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
    page_type: 0xffffefff(slab)
    raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122
    raw: ffff88802cd73020 000000008080007f 00000001ffffefff 0000000000000000
    page dumped because: kasan: bad access detected
    page_owner tracks the page as allocated
    page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 5103, tgid 2119833701 (syz-executor.4), ts 5103, free_ts 70804600828
      set_page_owner include/linux/page_owner.h:32 [inline]
      post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1490
      prep_new_page mm/page_alloc.c:1498 [inline]
      get_page_from_freelist+0x2e7e/0x2f40 mm/page_alloc.c:3454
      __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4712
      __alloc_pages_node_noprof include/linux/gfp.h:244 [inline]
      alloc_pages_node_noprof include/linux/gfp.h:271 [inline]
      alloc_slab_page+0x5f/0x120 mm/slub.c:2249
      allocate_slab+0x5a/0x2e0 mm/slub.c:2412
      new_slab mm/slub.c:2465 [inline]
      ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3615
      __slab_alloc+0x58/0xa0 mm/slub.c:3705
      __slab_alloc_node mm/slub.c:3758 [inline]
      slab_alloc_node mm/slub.c:3936 [inline]
      __do_kmalloc_node mm/slub.c:4068 [inline]
      kmalloc_node_track_caller_noprof+0x286/0x450 mm/slub.c:4089
      kstrdup+0x3a/0x80 mm/util.c:62
      device_rename+0xb5/0x1b0 drivers/base/core.c:4558
      dev_change_name+0x275/0x860 net/core/dev.c:1232
      do_setlink+0xa4b/0x41f0 net/core/rtnetlink.c:2864
      __rtnl_newlink net/core/rtnetlink.c:3680 [inline]
      rtnl_newlink+0x180b/0x20a0 net/core/rtnetlink.c:3727
      rtnetlink_rcv_msg+0x89b/0x10d0 net/core/rtnetlink.c:6594
      netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2559
      netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
      netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1361
    page last free pid 5146 tgid 5146 stack trace:
      reset_page_owner include/linux/page_owner.h:25 [inline]
      free_pages_prepare mm/page_alloc.c:1110 [inline]
      free_unref_page+0xd3c/0xec0 mm/page_alloc.c:2617
      discard_slab mm/slub.c:2511 [inline]
      __put_partials+0xeb/0x130 mm/slub.c:2980
      put_cpu_partial+0x17c/0x250 mm/slub.c:3055
      __slab_free+0x2ea/0x3d0 mm/slub.c:4254
      qlink_free mm/kasan/quarantine.c:163 [inline]
      qlist_free_all+0x9e/0x140 mm/kasan/quarantine.c:179
      kasan_quarantine_reduce+0x14f/0x170 mm/kasan/quarantine.c:286
      __kasan_slab_alloc+0x23/0x80 mm/kasan/common.c:322
      kasan_slab_alloc include/linux/kasan.h:201 [inline]
      slab_post_alloc_hook mm/slub.c:3888 [inline]
      slab_alloc_node mm/slub.c:3948 [inline]
      __do_kmalloc_node mm/slub.c:4068 [inline]
      __kmalloc_node_noprof+0x1d7/0x450 mm/slub.c:4076
      kmalloc_node_noprof include/linux/slab.h:681 [inline]
      kvmalloc_node_noprof+0x72/0x190 mm/util.c:634
      bucket_table_alloc lib/rhashtable.c:186 [inline]
      rhashtable_rehash_alloc+0x9e/0x290 lib/rhashtable.c:367
      rht_deferred_worker+0x4e1/0x2440 lib/rhashtable.c:427
      process_one_work kernel/workqueue.c:3218 [inline]
      process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3299
      worker_thread+0x86d/0xd70 kernel/workqueue.c:3380
      kthread+0x2f0/0x390 kernel/kthread.c:388
      ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
      ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
    
    Memory state around the buggy address:
     ffff88802cd73c80: 07 fc fc fc 05 fc fc fc 05 fc fc fc fa fc fc fc
     ffff88802cd73d00: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc
    >ffff88802cd73d80: fa fc fc fc 01 fc fc fc fa fc fc fc fa fc fc fc
                                   ^
     ffff88802cd73e00: fa fc fc fc fa fc fc fc 05 fc fc fc 07 fc fc fc
     ffff88802cd73e80: 07 fc fc fc 07 fc fc fc 07 fc fc fc 07 fc fc fc
    
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reported-by: syzbot <syzkaller@googlegroups.com>
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Reviewed-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Link: https://lore.kernel.org/r/20240404122051.2303764-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet [+ + +]
Author: Ryosuke Yasuoka <ryasuoka@redhat.com>
Date:   Wed Mar 20 09:54:10 2024 +0900

    nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
    
    [ Upstream commit d24b03535e5eb82e025219c2f632b485409c898f ]
    
    syzbot reported the following uninit-value access issue [1][2]:
    
    nci_rx_work() parses and processes received packet. When the payload
    length is zero, each message type handler reads uninitialized payload
    and KMSAN detects this issue. The receipt of a packet with a zero-size
    payload is considered unexpected, and therefore, such packets should be
    silently discarded.
    
    This patch resolved this issue by checking payload size before calling
    each message type handler codes.
    
    Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation")
    Reported-and-tested-by: syzbot+7ea9413ea6749baf5574@syzkaller.appspotmail.com
    Reported-and-tested-by: syzbot+29b5ca705d2e0f4a44d2@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=7ea9413ea6749baf5574 [1]
    Closes: https://syzkaller.appspot.com/bug?extid=29b5ca705d2e0f4a44d2 [2]
    Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com>
    Reviewed-by: Jeremy Cline <jeremy@jcline.org>
    Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nfs: fix UAF in direct writes [+ + +]
Author: Josef Bacik <josef@toxicpanda.com>
Date:   Fri Mar 1 11:49:57 2024 -0500

    nfs: fix UAF in direct writes
    
    [ Upstream commit 17f46b803d4f23c66cacce81db35fef3adb8f2af ]
    
    In production we have been hitting the following warning consistently
    
    ------------[ cut here ]------------
    refcount_t: underflow; use-after-free.
    WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0
    Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]
    RIP: 0010:refcount_warn_saturate+0x9c/0xe0
    PKRU: 55555554
    Call Trace:
     <TASK>
     ? __warn+0x9f/0x130
     ? refcount_warn_saturate+0x9c/0xe0
     ? report_bug+0xcc/0x150
     ? handle_bug+0x3d/0x70
     ? exc_invalid_op+0x16/0x40
     ? asm_exc_invalid_op+0x16/0x20
     ? refcount_warn_saturate+0x9c/0xe0
     nfs_direct_write_schedule_work+0x237/0x250 [nfs]
     process_one_work+0x12f/0x4a0
     worker_thread+0x14e/0x3b0
     ? ZSTD_getCParams_internal+0x220/0x220
     kthread+0xdc/0x120
     ? __btf_name_valid+0xa0/0xa0
     ret_from_fork+0x1f/0x30
    
    This is because we're completing the nfs_direct_request twice in a row.
    
    The source of this is when we have our commit requests to submit, we
    process them and send them off, and then in the completion path for the
    commit requests we have
    
    if (nfs_commit_end(cinfo.mds))
            nfs_direct_write_complete(dreq);
    
    However since we're submitting asynchronous requests we sometimes have
    one that completes before we submit the next one, so we end up calling
    complete on the nfs_direct_request twice.
    
    The only other place we use nfs_generic_commit_list() is in
    __nfs_commit_inode, which wraps this call in a
    
    nfs_commit_begin();
    nfs_commit_end();
    
    Which is a common pattern for this style of completion handling, one
    that is also repeated in the direct code with get_dreq()/put_dreq()
    calls around where we process events as well as in the completion paths.
    
    Fix this by using the same pattern for the commit requests.
    
    Before with my 200 node rocksdb stress running this warning would pop
    every 10ish minutes.  With my patch the stress test has been running for
    several hours without popping.
    
    Signed-off-by: Josef Bacik <josef@toxicpanda.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nilfs2: fix failure to detect DAT corruption in btree and direct mappings [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed Mar 13 19:58:26 2024 +0900

    nilfs2: fix failure to detect DAT corruption in btree and direct mappings
    
    [ Upstream commit f2f26b4a84a0ef41791bd2d70861c8eac748f4ba ]
    
    Patch series "nilfs2: fix kernel bug at submit_bh_wbc()".
    
    This resolves a kernel BUG reported by syzbot.  Since there are two
    flaws involved, I've made each one a separate patch.
    
    The first patch alone resolves the syzbot-reported bug, but I think
    both fixes should be sent to stable, so I've tagged them as such.
    
    This patch (of 2):
    
    Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data
    to a nilfs2 file system whose metadata is corrupted.
    
    There are two flaws involved in this issue.
    
    The first flaw is that when nilfs_get_block() locates a data block using
    btree or direct mapping, if the disk address translation routine
    nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata
    corruption, it can be passed back to nilfs_get_block().  This causes
    nilfs_get_block() to misidentify an existing block as non-existent,
    causing both data block lookup and insertion to fail inconsistently.
    
    The second flaw is that nilfs_get_block() returns a successful status in
    this inconsistent state.  This causes the caller __block_write_begin_int()
    or others to request a read even though the buffer is not mapped,
    resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()
    failing.
    
    This fixes the first issue by changing the return value to code -EINVAL
    when a conversion using DAT fails with code -ENOENT, avoiding the
    conflicting condition that leads to the kernel bug described above.  Here,
    code -EINVAL indicates that metadata corruption was detected during the
    block lookup, which will be properly handled as a file system error and
    converted to -EIO when passing through the nilfs2 bmap layer.
    
    Link: https://lkml.kernel.org/r/20240313105827.5296-1-konishi.ryusuke@gmail.com
    Link: https://lkml.kernel.org/r/20240313105827.5296-2-konishi.ryusuke@gmail.com
    Fixes: c3a7abf06ce7 ("nilfs2: support contiguous lookup of blocks")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: syzbot+cfed5b56649bddf80d6e@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=cfed5b56649bddf80d6e
    Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

nilfs2: prevent kernel bug at submit_bh_wbc() [+ + +]
Author: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Wed Mar 13 19:58:27 2024 +0900

    nilfs2: prevent kernel bug at submit_bh_wbc()
    
    [ Upstream commit 269cdf353b5bdd15f1a079671b0f889113865f20 ]
    
    Fix a bug where nilfs_get_block() returns a successful status when
    searching and inserting the specified block both fail inconsistently.  If
    this inconsistent behavior is not due to a previously fixed bug, then an
    unexpected race is occurring, so return a temporary error -EAGAIN instead.
    
    This prevents callers such as __block_write_begin_int() from requesting a
    read into a buffer that is not mapped, which would cause the BUG_ON check
    for the BH_Mapped flag in submit_bh_wbc() to fail.
    
    Link: https://lkml.kernel.org/r/20240313105827.5296-3-konishi.ryusuke@gmail.com
    Fixes: 1f5abe7e7dbc ("nilfs2: replace BUG_ON and BUG calls triggerable from ioctl")
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nvmem: meson-efuse: fix function pointer type mismatch [+ + +]
Author: Jerome Brunet <jbrunet@baylibre.com>
Date:   Sat Feb 24 11:40:23 2024 +0000

    nvmem: meson-efuse: fix function pointer type mismatch
    
    [ Upstream commit cbd38332c140829ab752ba4e727f98be5c257f18 ]
    
    clang-16 warns about casting functions to incompatible types, as is done
    here to call clk_disable_unprepare:
    
    drivers/nvmem/meson-efuse.c:78:12: error: cast from 'void (*)(struct clk *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
       78 |                                        (void(*)(void *))clk_disable_unprepare,
    
    The pattern of getting, enabling and setting a disable callback for a
    clock can be replaced with devm_clk_get_enabled(), which also fixes
    this warning.
    
    Fixes: 611fbca1c861 ("nvmem: meson-efuse: add peripheral clock")
    Cc: Stable@vger.kernel.org
    Reported-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
    Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Justin Stitt <justinstitt@google.com>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240224114023.85535-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
objtool: Add asm version of STACK_FRAME_NON_STANDARD [+ + +]
Author: Josh Poimboeuf <jpoimboe@kernel.org>
Date:   Thu Jan 21 15:29:23 2021 -0600

    objtool: Add asm version of STACK_FRAME_NON_STANDARD
    
    commit 081df94301e317e84c3413686043987da2c3e39d upstream.
    
    To be used for adding asm functions to the ignore list.  The "aw" is
    needed to help the ELF section metadata match GCC-created sections.
    Otherwise the linker creates duplicate sections instead of combining
    them.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Link: https://lore.kernel.org/r/8faa476f9a5ac89af27944ec184c89f95f3c6c49.1611263462.git.jpoimboe@redhat.com
    Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Octeontx2-af: fix pause frame configuration in GMP mode [+ + +]
Author: Hariprasad Kelam <hkelam@marvell.com>
Date:   Tue Mar 26 10:57:20 2024 +0530

    Octeontx2-af: fix pause frame configuration in GMP mode
    
    [ Upstream commit 40d4b4807cadd83fb3f46cc8cd67a945b5b25461 ]
    
    The Octeontx2 MAC block (CGX) has separate data paths (SMU and GMP) for
    different speeds, allowing for efficient data transfer.
    
    The previous patch which added pause frame configuration has a bug due
    to which pause frame feature is not working in GMP mode.
    
    This patch fixes the issue by configurating appropriate registers.
    
    Fixes: f7e086e754fe ("octeontx2-af: Pause frame configuration at cgx")
    Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/20240326052720.4441-1-hkelam@marvell.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
octeontx2-pf: check negative error code in otx2_open() [+ + +]
Author: Su Hui <suhui@nfschina.com>
Date:   Thu Mar 28 10:06:21 2024 +0800

    octeontx2-pf: check negative error code in otx2_open()
    
    commit e709acbd84fb6ef32736331b0147f027a3ef4c20 upstream.
    
    otx2_rxtx_enable() return negative error code such as -EIO,
    check -EIO rather than EIO to fix this problem.
    
    Fixes: c926252205c4 ("octeontx2-pf: Disable packet I/O for graceful exit")
    Signed-off-by: Su Hui <suhui@nfschina.com>
    Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
    Link: https://lore.kernel.org/r/20240328020620.4054692-1-suhui@nfschina.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
of: dynamic: Synchronize of_changeset_destroy() with the devlink removals [+ + +]
Author: Herve Codina <herve.codina@bootlin.com>
Date:   Mon Mar 25 16:21:26 2024 +0100

    of: dynamic: Synchronize of_changeset_destroy() with the devlink removals
    
    commit 8917e7385346bd6584890ed362985c219fe6ae84 upstream.
    
    In the following sequence:
      1) of_platform_depopulate()
      2) of_overlay_remove()
    
    During the step 1, devices are destroyed and devlinks are removed.
    During the step 2, OF nodes are destroyed but
    __of_changeset_entry_destroy() can raise warnings related to missing
    of_node_put():
      ERROR: memory leak, expected refcount 1 instead of 2 ...
    
    Indeed, during the devlink removals performed at step 1, the removal
    itself releasing the device (and the attached of_node) is done by a job
    queued in a workqueue and so, it is done asynchronously with respect to
    function calls.
    When the warning is present, of_node_put() will be called but wrongly
    too late from the workqueue job.
    
    In order to be sure that any ongoing devlink removals are done before
    the of_node destruction, synchronize the of_changeset_destroy() with the
    devlink removals.
    
    Fixes: 80dd33cf72d1 ("drivers: base: Fix device link removal")
    Cc: stable@vger.kernel.org
    Signed-off-by: Herve Codina <herve.codina@bootlin.com>
    Reviewed-by: Saravana Kannan <saravanak@google.com>
    Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
    Reviewed-by: Nuno Sa <nuno.sa@analog.com>
    Link: https://lore.kernel.org/r/20240325152140.198219-3-herve.codina@bootlin.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
panic: Flush kernel log buffer at the end [+ + +]
Author: John Ogness <john.ogness@linutronix.de>
Date:   Wed Feb 7 14:47:02 2024 +0106

    panic: Flush kernel log buffer at the end
    
    [ Upstream commit d988d9a9b9d180bfd5c1d353b3b176cb90d6861b ]
    
    If the kernel crashes in a context where printk() calls always
    defer printing (such as in NMI or inside a printk_safe section)
    then the final panic messages will be deferred to irq_work. But
    if irq_work is not available, the messages will not get printed
    unless explicitly flushed. The result is that the final
    "end Kernel panic" banner does not get printed.
    
    Add one final flush after the last printk() call to make sure
    the final panic messages make it out as well.
    
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20240207134103.1357162-14-john.ogness@linutronix.de
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
parisc: Avoid clobbering the C/B bits in the PSW with tophys and tovirt macros [+ + +]
Author: John David Anglin <dave.anglin@bell.net>
Date:   Fri Feb 23 16:40:51 2024 +0100

    parisc: Avoid clobbering the C/B bits in the PSW with tophys and tovirt macros
    
    [ Upstream commit 4603fbaa76b5e703b38ac8cc718102834eb6e330 ]
    
    Use add,l to avoid clobbering the C/B bits in the PSW.
    
    Signed-off-by: John David Anglin <dave.anglin@bell.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: stable@vger.kernel.org # v5.10+
    Signed-off-by: Sasha Levin <sashal@kernel.org>

parisc: Fix csum_ipv6_magic on 32-bit systems [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Feb 10 11:15:56 2024 -0800

    parisc: Fix csum_ipv6_magic on 32-bit systems
    
    [ Upstream commit 4408ba75e4ba80c91fde7e10bccccf388f5c09be ]
    
    Calculating the IPv6 checksum on 32-bit systems missed overflows when
    adding the proto+len fields into the checksum. This results in the
    following unit test failure.
    
        # test_csum_ipv6_magic: ASSERTION FAILED at lib/checksum_kunit.c:506
        Expected ( u64)csum_result == ( u64)expected, but
            ( u64)csum_result == 46722 (0xb682)
            ( u64)expected == 46721 (0xb681)
        not ok 5 test_csum_ipv6_magic
    
    This is probably rarely seen in the real world because proto+len are
    usually small values which will rarely result in overflows when calculating
    the checksum. However, the unit test code uses large values for the length
    field, causing the test to fail.
    
    Fix the problem by adding the missing carry into the final checksum.
    
    Cc: Palmer Dabbelt <palmer@rivosinc.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Charlie Jenkins <charlie@rivosinc.com>
    Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

parisc: Fix csum_ipv6_magic on 64-bit systems [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Feb 13 15:46:31 2024 -0800

    parisc: Fix csum_ipv6_magic on 64-bit systems
    
    [ Upstream commit 4b75b12d70506e31fc02356bbca60f8d5ca012d0 ]
    
    hppa 64-bit systems calculates the IPv6 checksum using 64-bit add
    operations. The last add folds protocol and length fields into the 64-bit
    result. While unlikely, this operation can overflow. The overflow can be
    triggered with a code sequence such as the following.
    
            /* try to trigger massive overflows */
            memset(tmp_buf, 0xff, sizeof(struct in6_addr));
            csum_result = csum_ipv6_magic((struct in6_addr *)tmp_buf,
                                          (struct in6_addr *)tmp_buf,
                                          0xffff, 0xff, 0xffffffff);
    
    Fix the problem by adding any overflows from the final add operation into
    the calculated checksum. Fortunately, we can do this without additional
    cost by replacing the add operation used to fold the checksum into 32 bit
    with "add,dc" to add in the missing carry.
    
    Cc: Palmer Dabbelt <palmer@rivosinc.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

parisc: Fix ip_fast_csum [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sat Feb 10 09:55:26 2024 -0800

    parisc: Fix ip_fast_csum
    
    [ Upstream commit a2abae8f0b638c31bb9799d9dd847306e0d005bd ]
    
    IP checksum unit tests report the following error when run on hppa/hppa64.
    
        # test_ip_fast_csum: ASSERTION FAILED at lib/checksum_kunit.c:463
        Expected ( u64)csum_result == ( u64)expected, but
            ( u64)csum_result == 33754 (0x83da)
            ( u64)expected == 10946 (0x2ac2)
        not ok 4 test_ip_fast_csum
    
    0x83da is the expected result if the IP header length is 20 bytes. 0x2ac2
    is the expected result if the IP header length is 24 bytes. The test fails
    with an IP header length of 24 bytes. It appears that ip_fast_csum()
    always returns the checksum for a 20-byte header, no matter how long
    the header actually is.
    
    Code analysis shows a suspicious assembler sequence in ip_fast_csum().
    
     "      addc            %0, %3, %0\n"
     "1:    ldws,ma         4(%1), %3\n"
     "      addib,<         0, %2, 1b\n"    <---
    
    While my understanding of HPPA assembler is limited, it does not seem
    to make much sense to subtract 0 from a register and to expect the result
    to ever be negative. Subtracting 1 from the length parameter makes more
    sense. On top of that, the operation should be repeated if and only if
    the result is still > 0, so change the suspicious instruction to
     "      addib,>         -1, %2, 1b\n"
    
    The IP checksum unit test passes after this change.
    
    Cc: Palmer Dabbelt <palmer@rivosinc.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Charlie Jenkins <charlie@rivosinc.com>
    Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

parisc: Strip upper 32 bit of sum in csum_ipv6_magic for 64-bit builds [+ + +]
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Tue Feb 27 12:33:51 2024 -0800

    parisc: Strip upper 32 bit of sum in csum_ipv6_magic for 64-bit builds
    
    [ Upstream commit 0568b6f0d863643db2edcc7be31165740c89fa82 ]
    
    IPv6 checksum tests with unaligned addresses on 64-bit builds result
    in unexpected failures.
    
    Expected expected == csum_result, but
        expected == 46591 (0xb5ff)
        csum_result == 46381 (0xb52d)
    with alignment offset 1
    
    Oddly enough, the problem disappeared after adding test code into
    the beginning of csum_ipv6_magic().
    
    As it turns out, the 'sum' parameter of csum_ipv6_magic() is declared as
    __wsum, which is a 32-bit variable. However, it is treated as 64-bit
    variable in the 64-bit assembler code. Tests showed that the upper 32 bit
    of the register used to pass the variable are _not_ cleared when entering
    the function. This can result in checksum calculation errors.
    
    Clearing the upper 32 bit of 'sum' as first operation in the assembler
    code fixes the problem.
    
    Acked-by: Helge Deller <deller@gmx.de>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/AER: Block runtime suspend when handling errors [+ + +]
Author: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Date:   Mon Feb 12 13:01:35 2024 +0100

    PCI/AER: Block runtime suspend when handling errors
    
    [ Upstream commit 002bf2fbc00e5c4b95fb167287e2ae7d1973281e ]
    
    PM runtime can be done simultaneously with AER error handling.  Avoid that
    by using pm_runtime_get_sync() before and pm_runtime_put() after reset in
    pcie_do_recovery() for all recovering devices.
    
    pm_runtime_get_sync() will increase dev->power.usage_count counter to
    prevent any possible future request to runtime suspend a device.  It will
    also resume a device, if it was previously in D3hot state.
    
    I tested with igc device by doing simultaneous aer_inject and rpm
    suspend/resume via /sys/bus/pci/devices/PCI_ID/power/control and can
    reproduce:
    
      igc 0000:02:00.0: not ready 65535ms after bus reset; giving up
      pcieport 0000:00:1c.2: AER: Root Port link has been reset (-25)
      pcieport 0000:00:1c.2: AER: subordinate device reset failed
      pcieport 0000:00:1c.2: AER: device recovery failed
      igc 0000:02:00.0: Unable to change power state from D3hot to D0, device inaccessible
    
    The problem disappears when this patch is applied.
    
    Link: https://lore.kernel.org/r/20240212120135.146068-1-stanislaw.gruszka@linux.intel.com
    Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Acked-by: Rafael J. Wysocki <rafael@kernel.org>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/ASPM: Make Intel DG2 L1 acceptable latency unlimited [+ + +]
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Tue Apr 5 12:38:10 2022 +0300

    PCI/ASPM: Make Intel DG2 L1 acceptable latency unlimited
    
    [ Upstream commit 03038d84ace72678a9944524508f218a00377dc0 ]
    
    Intel DG2 discrete graphics PCIe endpoints advertise L1 acceptable exit
    latency to be < 1us even though they can actually tolerate unlimited exit
    latencies just fine. Quirk the L1 acceptable exit latency for these
    endpoints to be unlimited so ASPM L1 can be enabled.
    
    [bhelgaas: use FIELD_GET/FIELD_PREP, wordsmith comment & commit log]
    Link: https://lore.kernel.org/r/20220405093810.76613-1-mika.westerberg@linux.intel.com
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
    Stable-dep-of: 627c6db20703 ("PCI/DPC: Quirk PIO log size for Intel Raptor Lake Root Ports")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/DPC: Quirk PIO log size for certain Intel Root Ports [+ + +]
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Tue Aug 16 13:20:42 2022 +0300

    PCI/DPC: Quirk PIO log size for certain Intel Root Ports
    
    [ Upstream commit 5459c0b7046752e519a646e1c2404852bb628459 ]
    
    Some Root Ports on Intel Tiger Lake and Alder Lake systems support the RP
    Extensions for DPC and the RP PIO Log registers but incorrectly advertise
    an RP PIO Log Size of zero.  This means the kernel complains that:
    
      DPC: RP PIO log size 0 is invalid
    
    and if DPC is triggered, the DPC driver will not dump the RP PIO Log
    registers when it should.
    
    This is caused by a BIOS bug and should be fixed the BIOS for future CPUs.
    
    Add a quirk to set the correct RP PIO Log size for the affected Root Ports.
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=209943
    Link: https://lore.kernel.org/r/20220816102042.69125-1-mika.westerberg@linux.intel.com
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
    Stable-dep-of: 627c6db20703 ("PCI/DPC: Quirk PIO log size for Intel Raptor Lake Root Ports")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI/DPC: Quirk PIO log size for Intel Ice Lake Root Ports [+ + +]
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Thu May 11 15:19:05 2023 +0300

    PCI/DPC: Quirk PIO log size for Intel Ice Lake Root Ports
    
    commit 3b8803494a0612acdeee714cb72aa142b1e05ce5 upstream.
    
    Commit 5459c0b70467 ("PCI/DPC: Quirk PIO log size for certain Intel Root
    Ports") added quirks for Tiger and Alder Lake Root Ports but missed that
    the same issue exists also in the previous generation, Ice Lake.
    
    Apply the quirk for Ice Lake Root Ports as well.  This prevents kernel
    complaints like:
    
      DPC: RP PIO log size 0 is invalid
    
    and also enables the DPC driver to dump the RP PIO Log registers when DPC
    is triggered.
    
    [bhelgaas: add dmesg warning and RP PIO Log dump info]
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=209943
    Link: https://lore.kernel.org/r/20230511121905.73949-1-mika.westerberg@linux.intel.com
    Reported-by: Mark Blakeney <mark.blakeney@bullet-systems.net>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI/DPC: Quirk PIO log size for Intel Raptor Lake Root Ports [+ + +]
Author: Paul Menzel <pmenzel@molgen.mpg.de>
Date:   Tue Mar 5 12:30:56 2024 +0100

    PCI/DPC: Quirk PIO log size for Intel Raptor Lake Root Ports
    
    [ Upstream commit 627c6db20703b5d18d928464f411d0d4ec327508 ]
    
    Commit 5459c0b70467 ("PCI/DPC: Quirk PIO log size for certain Intel Root
    Ports") and commit 3b8803494a06 ("PCI/DPC: Quirk PIO log size for Intel Ice
    Lake Root Ports") add quirks for Ice, Tiger and Alder Lake Root Ports.
    System firmware for Raptor Lake still has the bug, so Linux logs the
    warning below on several Raptor Lake systems like Dell Precision 3581 with
    Intel Raptor Lake processor (0W18NX) system firmware/BIOS version 1.10.1.
    
      pci 0000:00:07.0: [8086:a76e] type 01 class 0x060400
      pci 0000:00:07.0: DPC: RP PIO log size 0 is invalid
      pci 0000:00:07.1: [8086:a73f] type 01 class 0x060400
      pci 0000:00:07.1: DPC: RP PIO log size 0 is invalid
    
    Apply the quirk for Raptor Lake Root Ports as well.
    
    This also enables the DPC driver to dump the RP PIO Log registers when DPC
    is triggered.
    
    Link: https://lore.kernel.org/r/20240305113057.56468-1-pmenzel@molgen.mpg.de
    Reported-by: Niels van Aert <nvaert1986@hotmail.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218560
    Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Cc: <stable@vger.kernel.org>
    Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
    Cc: Niels van Aert <nvaert1986@hotmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/ERR: Cache RCEC EA Capability offset in pci_init_capabilities() [+ + +]
Author: Sean V Kelley <sean.v.kelley@intel.com>
Date:   Fri Nov 20 16:10:24 2020 -0800

    PCI/ERR: Cache RCEC EA Capability offset in pci_init_capabilities()
    
    [ Upstream commit 90655631988f8f501529e6de5f13614389717ead ]
    
    Extend support for Root Complex Event Collectors by decoding and caching
    the RCEC Endpoint Association Extended Capabilities when enumerating. Use
    that cached information for later error source reporting. See PCIe r5.0,
    sec 7.9.10.
    
    Co-developed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Link: https://lore.kernel.org/r/20201121001036.8560-4-sean.v.kelley@intel.com
    Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # non-native/no RCEC
    Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
    Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Stable-dep-of: 627c6db20703 ("PCI/DPC: Quirk PIO log size for Intel Raptor Lake Root Ports")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI/ERR: Clear AER status only when we control AER [+ + +]
Author: Sean V Kelley <sean.v.kelley@intel.com>
Date:   Tue Nov 24 10:55:30 2020 -0600

    PCI/ERR: Clear AER status only when we control AER
    
    [ Upstream commit aa344bc8b727b47b4350b59d8166216a3f351e55 ]
    
    In some cases a bridge may not exist as the hardware controlling may be
    handled only by firmware and so is not visible to the OS. This scenario is
    also possible in future use cases involving non-native use of RCECs by
    firmware. In this scenario, we expect the platform to retain control of the
    bridge and to clear error status itself.
    
    Clear error status only when the OS has native control of AER.
    
    Signed-off-by: Sean V Kelley <sean.v.kelley@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Stable-dep-of: 002bf2fbc00e ("PCI/AER: Block runtime suspend when handling errors")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI/PM: Drain runtime-idle callbacks before driver removal [+ + +]
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Mar 5 11:45:38 2024 +0100

    PCI/PM: Drain runtime-idle callbacks before driver removal
    
    [ Upstream commit 9d5286d4e7f68beab450deddbb6a32edd5ecf4bf ]
    
    A race condition between the .runtime_idle() callback and the .remove()
    callback in the rtsx_pcr PCI driver leads to a kernel crash due to an
    unhandled page fault [1].
    
    The problem is that rtsx_pci_runtime_idle() is not expected to be running
    after pm_runtime_get_sync() has been called, but the latter doesn't really
    guarantee that.  It only guarantees that the suspend and resume callbacks
    will not be running when it returns.
    
    However, if a .runtime_idle() callback is already running when
    pm_runtime_get_sync() is called, the latter will notice that the runtime PM
    status of the device is RPM_ACTIVE and it will return right away without
    waiting for the former to complete.  In fact, it cannot wait for
    .runtime_idle() to complete because it may be called from that callback (it
    arguably does not make much sense to do that, but it is not strictly
    prohibited).
    
    Thus in general, whoever is providing a .runtime_idle() callback needs
    to protect it from running in parallel with whatever code runs after
    pm_runtime_get_sync().  [Note that .runtime_idle() will not start after
    pm_runtime_get_sync() has returned, but it may continue running then if it
    has started earlier.]
    
    One way to address that race condition is to call pm_runtime_barrier()
    after pm_runtime_get_sync() (not before it, because a nonzero value of the
    runtime PM usage counter is necessary to prevent runtime PM callbacks from
    being invoked) to wait for the .runtime_idle() callback to complete should
    it be running at that point.  A suitable place for doing that is in
    pci_device_remove() which calls pm_runtime_get_sync() before removing the
    driver, so it may as well call pm_runtime_barrier() subsequently, which
    will prevent the race in question from occurring, not just in the rtsx_pcr
    driver, but in any PCI drivers providing .runtime_idle() callbacks.
    
    Link: https://lore.kernel.org/lkml/20240229062201.49500-1-kai.heng.feng@canonical.com/ # [1]
    Link: https://lore.kernel.org/r/5761426.DvuYhMxLoT@kreacher
    Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Tested-by: Ricky Wu <ricky_wu@realtek.com>
    Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
PCI: Cache PCIe Device Capabilities register [+ + +]
Author: Amey Narkhede <ameynarkhede03@gmail.com>
Date:   Tue Aug 17 23:34:52 2021 +0530

    PCI: Cache PCIe Device Capabilities register
    
    [ Upstream commit 69139244806537f9d51364f37fe146bb2ee88a05 ]
    
    Add a new member called devcap in struct pci_dev for caching the PCIe
    Device Capabilities register to avoid reading PCI_EXP_DEVCAP multiple
    times.
    
    Refactor pcie_has_flr() to use cached device capabilities.
    
    Link: https://lore.kernel.org/r/20210817180500.1253-2-ameynarkhede03@gmail.com
    Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Raphael Norwitz <raphael.norwitz@nutanix.com>
    Stable-dep-of: 627c6db20703 ("PCI/DPC: Quirk PIO log size for Intel Raptor Lake Root Ports")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: Drop pci_device_remove() test of pci_dev->driver [+ + +]
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Mon Oct 4 14:59:25 2021 +0200

    PCI: Drop pci_device_remove() test of pci_dev->driver
    
    [ Upstream commit 097d9d414433315122f759ee6c2d8a7417a8ff0f ]
    
    When the driver core calls pci_device_remove(), there is a driver bound
    to the device, so pci_dev->driver is never NULL.
    
    Remove the unnecessary test of pci_dev->driver.
    
    Link: https://lore.kernel.org/r/20211004125935.2300113-2-u.kleine-koenig@pengutronix.de
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Stable-dep-of: 9d5286d4e7f6 ("PCI/PM: Drain runtime-idle callbacks before driver removal")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: dwc: endpoint: Fix advertised resizable BAR size [+ + +]
Author: Niklas Cassel <cassel@kernel.org>
Date:   Thu Mar 7 12:15:20 2024 +0100

    PCI: dwc: endpoint: Fix advertised resizable BAR size
    
    [ Upstream commit 72e34b8593e08a0ee759b7a038e0b178418ea6f8 ]
    
    The commit message in commit fc9a77040b04 ("PCI: designware-ep: Configure
    Resizable BAR cap to advertise the smallest size") claims that it modifies
    the Resizable BAR capability to only advertise support for 1 MB size BARs.
    
    However, the commit writes all zeroes to PCI_REBAR_CAP (the register which
    contains the possible BAR sizes that a BAR be resized to).
    
    According to the spec, it is illegal to not have a bit set in
    PCI_REBAR_CAP, and 1 MB is the smallest size allowed.
    
    Set bit 4 in PCI_REBAR_CAP, so that we actually advertise support for a
    1 MB BAR size.
    
    Before:
            Capabilities: [2e8 v1] Physical Resizable BAR
                    BAR 0: current size: 1MB
                    BAR 1: current size: 1MB
                    BAR 2: current size: 1MB
                    BAR 3: current size: 1MB
                    BAR 4: current size: 1MB
                    BAR 5: current size: 1MB
    After:
            Capabilities: [2e8 v1] Physical Resizable BAR
                    BAR 0: current size: 1MB, supported: 1MB
                    BAR 1: current size: 1MB, supported: 1MB
                    BAR 2: current size: 1MB, supported: 1MB
                    BAR 3: current size: 1MB, supported: 1MB
                    BAR 4: current size: 1MB, supported: 1MB
                    BAR 5: current size: 1MB, supported: 1MB
    
    Fixes: fc9a77040b04 ("PCI: designware-ep: Configure Resizable BAR cap to advertise the smallest size")
    Link: https://lore.kernel.org/linux-pci/20240307111520.3303774-1-cassel@kernel.org
    Signed-off-by: Niklas Cassel <cassel@kernel.org>
    Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
    Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
    Cc: <stable@vger.kernel.org> # 5.2
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PCI: Work around Intel I210 ROM BAR overlap defect [+ + +]
Author: Bjorn Helgaas <bhelgaas@google.com>
Date:   Tue Dec 21 10:45:07 2021 -0600

    PCI: Work around Intel I210 ROM BAR overlap defect
    
    [ Upstream commit 500b55b05d0a21c4adddf4c3b29ee6f32b502046 ]
    
    Per PCIe r5, sec 7.5.1.2.4, a device must not claim accesses to its
    Expansion ROM unless both the Memory Space Enable and the Expansion ROM
    Enable bit are set.  But apparently some Intel I210 NICs don't work
    correctly if the ROM BAR overlaps another BAR, even if the Expansion ROM is
    disabled.
    
    Michael reported that on a Kontron SMARC-sAL28 ARM64 system with U-Boot
    v2021.01-rc3, the ROM BAR overlaps BAR 3, and networking doesn't work at
    all:
    
      BAR 0: 0x40000000 (32-bit, non-prefetchable) [size=1M]
      BAR 3: 0x40200000 (32-bit, non-prefetchable) [size=16K]
      ROM:   0x40200000 (disabled) [size=1M]
    
      NETDEV WATCHDOG: enP2p1s0 (igb): transmit queue 0 timed out
      Hardware name: Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier (DT)
      igb 0002:01:00.0 enP2p1s0: Reset adapter
    
    Previously, pci_std_update_resource() wrote the assigned ROM address to the
    BAR only when the ROM was enabled.  This meant that the I210 ROM BAR could
    be left with an address assigned by firmware, which might overlap with
    other BARs.
    
    Quirk these I210 devices so pci_std_update_resource() always writes the
    assigned address to the ROM BAR, whether or not the ROM is enabled.
    
    Link: https://lore.kernel.org/r/20211223163754.GA1267351@bhelgaas
    Link: https://lore.kernel.org/r/20201230185317.30915-1-michael@walle.cc
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=211105
    Reported-by: Michael Walle <michael@walle.cc>
    Tested-by: Michael Walle <michael@walle.cc>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Stable-dep-of: 627c6db20703 ("PCI/DPC: Quirk PIO log size for Intel Raptor Lake Root Ports")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
perf/core: Fix reentry problem in perf_output_read_group() [+ + +]
Author: Yang Jihong <yangjihong1@huawei.com>
Date:   Fri Sep 2 16:29:18 2022 +0800

    perf/core: Fix reentry problem in perf_output_read_group()
    
    commit 6b959ba22d34ca793ffdb15b5715457c78e38b1a upstream.
    
    perf_output_read_group may respond to IPI request of other cores and invoke
    __perf_install_in_context function. As a result, hwc configuration is modified.
    causing inconsistency and unexpected consequences.
    
    Interrupts are not disabled when perf_output_read_group reads PMU counter.
    In this case, IPI request may be received from other cores.
    As a result, PMU configuration is modified and an error occurs when
    reading PMU counter:
    
                         CPU0                                         CPU1
                                                          __se_sys_perf_event_open
                                                            perf_install_in_context
      perf_output_read_group                                  smp_call_function_single
        for_each_sibling_event(sub, leader) {                   generic_exec_single
          if ((sub != event) &&                                   remote_function
              (sub->state == PERF_EVENT_STATE_ACTIVE))                    |
      <enter IPI handler: __perf_install_in_context>   <----RAISE IPI-----+
      __perf_install_in_context
        ctx_resched
          event_sched_out
            armpmu_del
              ...
              hwc->idx = -1; // event->hwc.idx is set to -1
      ...
      <exit IPI>
                  sub->pmu->read(sub);
                    armpmu_read
                      armv8pmu_read_counter
                        armv8pmu_read_hw_counter
                          int idx = event->hw.idx; // idx = -1
                          u64 val = armv8pmu_read_evcntr(idx);
                            u32 counter = ARMV8_IDX_TO_COUNTER(idx); // invalid counter = 30
                            read_pmevcntrn(counter) // undefined instruction
    
    Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20220902082918.179248-1-yangjihong1@huawei.com
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
phy: tegra: xusb: Add API to retrieve the port number of phy [+ + +]
Author: Wayne Chang <waynec@nvidia.com>
Date:   Thu Mar 7 11:03:27 2024 +0800

    phy: tegra: xusb: Add API to retrieve the port number of phy
    
    [ Upstream commit d843f031d9e90462253015bc0bd9e3852d206bf2 ]
    
    This patch introduces a new API, tegra_xusb_padctl_get_port_number,
    to the Tegra XUSB Pad Controller driver. This API is used to identify
    the USB port that is associated with a given PHY.
    
    The function takes a PHY pointer for either a USB2 PHY or USB3 PHY as input
    and returns the corresponding port number. If the PHY pointer is invalid,
    it returns -ENODEV.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Wayne Chang <waynec@nvidia.com>
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Link: https://lore.kernel.org/r/20240307030328.1487748-2-waynec@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pinctrl: renesas: checker: Limit cfg reg enum checks to provided IDs [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Mon Jan 22 14:43:38 2024 +0100

    pinctrl: renesas: checker: Limit cfg reg enum checks to provided IDs
    
    [ Upstream commit 3803584a4e9b65bb5b013f862f55c5055aa86c25 ]
    
    If the number of provided enum IDs in a variable width config register
    description does not match the expected number, the checker uses the
    expected number for validating the individual enum IDs.
    
    However, this may cause out-of-bounds accesses on the array holding the
    enum IDs, leading to bogus enum_id conflict warnings.  Worse, if the bug
    is an incorrect bit field description (e.g. accidentally using "12"
    instead of "-12" for a reserved field), thousands of warnings may be
    printed, overflowing the kernel log buffer.
    
    Fix this by limiting the enum ID check to the number of provided enum
    IDs.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://lore.kernel.org/r/c7385f44f2faebb8856bcbb4e908d846fc1531fb.1705930809.git.geert+renesas@glider.be
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
platform/x86: touchscreen_dmi: Add an extra entry for a variant of the Chuwi Vi8 tablet [+ + +]
Author: Alban Boyé <alban.boye@protonmail.com>
Date:   Tue Feb 27 22:40:17 2024 +0000

    platform/x86: touchscreen_dmi: Add an extra entry for a variant of the Chuwi Vi8 tablet
    
    [ Upstream commit 1266e2efb7512dbf20eac820ca2ed34de6b1c3e7 ]
    
    Signed-off-by: Alban Boyé <alban.boye@protonmail.com>
    Link: https://lore.kernel.org/r/20240227223919.11587-1-alban.boye@protonmail.com
    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>

 
PM: sleep: wakeirq: fix wake irq warning in system suspend [+ + +]
Author: Qingliang Li <qingliang.li@mediatek.com>
Date:   Fri Mar 1 17:26:57 2024 +0800

    PM: sleep: wakeirq: fix wake irq warning in system suspend
    
    [ Upstream commit e7a7681c859643f3f2476b2a28a494877fd89442 ]
    
    When driver uses pm_runtime_force_suspend() as the system suspend callback
    function and registers the wake irq with reverse enable ordering, the wake
    irq will be re-enabled when entering system suspend, triggering an
    'Unbalanced enable for IRQ xxx' warning. In this scenario, the call
    sequence during system suspend is as follows:
      suspend_devices_and_enter()
        -> dpm_suspend_start()
          -> dpm_run_callback()
            -> pm_runtime_force_suspend()
              -> dev_pm_enable_wake_irq_check()
              -> dev_pm_enable_wake_irq_complete()
    
        -> suspend_enter()
          -> dpm_suspend_noirq()
            -> device_wakeup_arm_wake_irqs()
              -> dev_pm_arm_wake_irq()
    
    To fix this issue, complete the setting of WAKE_IRQ_DEDICATED_ENABLED flag
    in dev_pm_enable_wake_irq_complete() to avoid redundant irq enablement.
    
    Fixes: 8527beb12087 ("PM: sleep: wakeirq: fix wake irq arming")
    Reviewed-by: Dhruva Gole <d-gole@ti.com>
    Signed-off-by: Qingliang Li <qingliang.li@mediatek.com>
    Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
    Cc: 5.16+ <stable@vger.kernel.org> # 5.16+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

PM: suspend: Set mem_sleep_current during kernel command line setup [+ + +]
Author: Maulik Shah <quic_mkshah@quicinc.com>
Date:   Thu Feb 29 12:14:59 2024 +0530

    PM: suspend: Set mem_sleep_current during kernel command line setup
    
    [ Upstream commit 9bc4ffd32ef8943f5c5a42c9637cfd04771d021b ]
    
    psci_init_system_suspend() invokes suspend_set_ops() very early during
    bootup even before kernel command line for mem_sleep_default is setup.
    This leads to kernel command line mem_sleep_default=s2idle not working
    as mem_sleep_current gets changed to deep via suspend_set_ops() and never
    changes back to s2idle.
    
    Set mem_sleep_current along with mem_sleep_default during kernel command
    line setup as default suspend mode.
    
    Fixes: faf7ec4a92c0 ("drivers: firmware: psci: add system suspend support")
    CC: stable@vger.kernel.org # 5.4+
    Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc/fsl: Fix mfpmr build errors with newer binutils [+ + +]
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Thu Feb 29 23:25:19 2024 +1100

    powerpc/fsl: Fix mfpmr build errors with newer binutils
    
    [ Upstream commit 5f491356b7149564ab22323ccce79c8d595bfd0c ]
    
    Binutils 2.38 complains about the use of mfpmr when building
    ppc6xx_defconfig:
    
        CC      arch/powerpc/kernel/pmc.o
      {standard input}: Assembler messages:
      {standard input}:45: Error: unrecognized opcode: `mfpmr'
      {standard input}:56: Error: unrecognized opcode: `mtpmr'
    
    This is because by default the kernel is built with -mcpu=powerpc, and
    the mt/mfpmr instructions are not defined.
    
    It can be avoided by enabling CONFIG_E300C3_CPU, but just adding that to
    the defconfig will leave open the possibility of randconfig failures.
    
    So add machine directives around the mt/mfpmr instructions to tell
    binutils how to assemble them.
    
    Cc: stable@vger.kernel.org
    Reported-by: Jan-Benedict Glaw <jbglaw@lug-owl.de>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240229122521.762431-3-mpe@ellerman.id.au
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
powerpc: xor_vmx: Add '-mhard-float' to CFLAGS [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Sat Jan 27 11:07:43 2024 -0700

    powerpc: xor_vmx: Add '-mhard-float' to CFLAGS
    
    commit 35f20786c481d5ced9283ff42de5c69b65e5ed13 upstream.
    
    arch/powerpc/lib/xor_vmx.o is built with '-msoft-float' (from the main
    powerpc Makefile) and '-maltivec' (from its CFLAGS), which causes an
    error when building with clang after a recent change in main:
    
      error: option '-msoft-float' cannot be specified with '-maltivec'
      make[6]: *** [scripts/Makefile.build:243: arch/powerpc/lib/xor_vmx.o] Error 1
    
    Explicitly add '-mhard-float' before '-maltivec' in xor_vmx.o's CFLAGS
    to override the previous inclusion of '-msoft-float' (as the last option
    wins), which matches how other areas of the kernel use '-maltivec', such
    as AMDGPU.
    
    Cc: stable@vger.kernel.org
    Closes: https://github.com/ClangBuiltLinux/linux/issues/1986
    Link: https://github.com/llvm/llvm-project/commit/4792f912b232141ecba4cbae538873be3c28556c
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://msgid.link/20240127-ppc-xor_vmx-drop-msoft-float-v1-1-f24140e81376@kernel.org
    [nathan: Fixed conflicts due to lack of 04e85bbf71c9 in older trees]
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
printk/console: Split out code that enables default console [+ + +]
Author: Petr Mladek <pmladek@suse.com>
Date:   Mon Nov 22 14:26:45 2021 +0100

    printk/console: Split out code that enables default console
    
    [ Upstream commit ed758b30d541e9bf713cd58612a4414e57dc6d73 ]
    
    Put the code enabling a console by default into a separate function
    called try_enable_default_console().
    
    Rename try_enable_new_console() to try_enable_preferred_console() to
    make the purpose of the different variants more clear.
    
    It is a code refactoring without any functional change.
    
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
    Link: https://lore.kernel.org/r/20211122132649.12737-2-pmladek@suse.com
    Stable-dep-of: 801410b26a0e ("serial: Lock console when calling into driver before registration")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
printk: Update @console_may_schedule in console_trylock_spinning() [+ + +]
Author: John Ogness <john.ogness@linutronix.de>
Date:   Mon Feb 26 13:07:24 2024 +0106

    printk: Update @console_may_schedule in console_trylock_spinning()
    
    [ Upstream commit 8076972468584d4a21dab9aa50e388b3ea9ad8c7 ]
    
    console_trylock_spinning() may takeover the console lock from a
    schedulable context. Update @console_may_schedule to make sure it
    reflects a trylock acquire.
    
    Reported-by: Mukesh Ojha <quic_mojha@quicinc.com>
    Closes: https://lore.kernel.org/lkml/20240222090538.23017-1-quic_mojha@quicinc.com
    Fixes: dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes")
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/875xybmo2z.fsf@jogness.linutronix.de
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
pstore/zone: Add a null pointer check to the psz_kmsg_read [+ + +]
Author: Kunwu Chan <chentao@kylinos.cn>
Date:   Thu Jan 18 18:02:06 2024 +0800

    pstore/zone: Add a null pointer check to the psz_kmsg_read
    
    [ Upstream commit 98bc7e26e14fbb26a6abf97603d59532475e97f8 ]
    
    kasprintf() returns a pointer to dynamically allocated memory
    which can be NULL upon failure. Ensure the allocation was successful
    by checking the pointer validity.
    
    Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
    Link: https://lore.kernel.org/r/20240118100206.213928-1-chentao@kylinos.cn
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
r8169: fix issue caused by buggy BIOS on certain boards with RTL8168d [+ + +]
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sat Mar 30 12:49:02 2024 +0100

    r8169: fix issue caused by buggy BIOS on certain boards with RTL8168d
    
    commit 5d872c9f46bd2ea3524af3c2420a364a13667135 upstream.
    
    On some boards with this chip version the BIOS is buggy and misses
    to reset the PHY page selector. This results in the PHY ID read
    accessing registers on a different page, returning a more or
    less random value. Fix this by resetting the page selector first.
    
    Fixes: f1e911d5d0df ("r8169: add basic phylib support")
    Cc: stable@vger.kernel.org
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://lore.kernel.org/r/64f2055e-98b8-45ec-8568-665e3d54d4e6@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
RDMA/cm: add timeout to cm_destroy_id wait [+ + +]
Author: Manjunath Patil <manjunath.b.patil@oracle.com>
Date:   Fri Mar 8 22:33:23 2024 -0800

    RDMA/cm: add timeout to cm_destroy_id wait
    
    [ Upstream commit 96d9cbe2f2ff7abde021bac75eafaceabe9a51fa ]
    
    Add timeout to cm_destroy_id, so that userspace can trigger any data
    collection that would help in analyzing the cause of delay in destroying
    the cm_id.
    
    New noinline function helps dtrace/ebpf programs to hook on to it.
    Existing functionality isn't changed except triggering a probe-able new
    function at every timeout interval.
    
    We have seen cases where CM messages stuck with MAD layer (either due to
    software bug or faulty HCA), leading to cm_id getting stuck in the
    following call stack. This patch helps in resolving such issues faster.
    
    kernel: ... INFO: task XXXX:56778 blocked for more than 120 seconds.
    ...
            Call Trace:
            __schedule+0x2bc/0x895
            schedule+0x36/0x7c
            schedule_timeout+0x1f6/0x31f
            ? __slab_free+0x19c/0x2ba
            wait_for_completion+0x12b/0x18a
            ? wake_up_q+0x80/0x73
            cm_destroy_id+0x345/0x610 [ib_cm]
            ib_destroy_cm_id+0x10/0x20 [ib_cm]
            rdma_destroy_id+0xa8/0x300 [rdma_cm]
            ucma_destroy_id+0x13e/0x190 [rdma_ucm]
            ucma_write+0xe0/0x160 [rdma_ucm]
            __vfs_write+0x3a/0x16d
            vfs_write+0xb2/0x1a1
            ? syscall_trace_enter+0x1ce/0x2b8
            SyS_write+0x5c/0xd3
            do_syscall_64+0x79/0x1b9
            entry_SYSCALL_64_after_hwframe+0x16d/0x0
    
    Signed-off-by: Manjunath Patil <manjunath.b.patil@oracle.com>
    Link: https://lore.kernel.org/r/20240309063323.458102-1-manjunath.b.patil@oracle.com
    Signed-off-by: Leon Romanovsky <leon@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default" [+ + +]
Author: Daniel Drake <drake@endlessos.org>
Date:   Wed Feb 28 08:53:16 2024 +0100

    Revert "ACPI: PM: Block ASUS B1400CEAE from suspend to idle by default"
    
    [ Upstream commit cb98555fcd8eee98c30165537c7e394f3a66e809 ]
    
    This reverts commit d52848620de00cde4a3a5df908e231b8c8868250, which was
    originally put in place to work around a s2idle failure on this platform
    where the NVMe device was inaccessible upon resume.
    
    After extended testing, we found that the firmware's implementation of S3
    is buggy and intermittently fails to wake up the system. We need to revert
    to s2idle mode.
    
    The NVMe issue has now been solved more precisely in the commit titled
    "PCI: Disable D3cold on Asus B1400 PCI-NVMe bridge"
    
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=215742
    Link: https://lore.kernel.org/r/20240228075316.7404-2-drake@endlessos.org
    Signed-off-by: Daniel Drake <drake@endlessos.org>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Jian-Hong Pan <jhp@endlessos.org>
    Acked-by: Rafael J. Wysocki <rafael@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"" [+ + +]
Author: Song Liu <song@kernel.org>
Date:   Thu Jan 25 00:21:31 2024 -0800

    Revert "Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d""
    
    [ Upstream commit 3445139e3a594be77eff48bc17eff67cf983daed ]
    
    This reverts commit bed9e27baf52a09b7ba2a3714f1e24e17ced386d.
    
    The original set [1][2] was expected to undo a suboptimal fix in [2], and
    replace it with a better fix [1]. However, as reported by Dan Moulding [2]
    causes an issue with raid5 with journal device.
    
    Revert [2] for now to close the issue. We will follow up on another issue
    reported by Juxiao Bi, as [2] is expected to fix it. We believe this is a
    good trade-off, because the latter issue happens less freqently.
    
    In the meanwhile, we will NOT revert [1], as it contains the right logic.
    
    [1] commit d6e035aad6c0 ("md: bypass block throttle for superblock update")
    [2] commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
    
    Reported-by: Dan Moulding <dan@danm.net>
    Closes: https://lore.kernel.org/linux-raid/20240123005700.9302-1-dan@danm.net/
    Fixes: bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")
    Cc: stable@vger.kernel.org # v5.19+
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Yu Kuai <yukuai3@huawei.com>
    Signed-off-by: Song Liu <song@kernel.org>
    Reviewed-by: Yu Kuai <yukuai3@huawei.com>
    Link: https://lore.kernel.org/r/20240125082131.788600-1-song@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "usb: phy: generic: Get the vbus supply" [+ + +]
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
Date:   Thu Mar 14 10:26:27 2024 +0100

    Revert "usb: phy: generic: Get the vbus supply"
    
    [ Upstream commit fdada0db0b2ae2addef4ccafe50937874dbeeebe ]
    
    This reverts commit 75fd6485cccef269ac9eb3b71cf56753341195ef.
    This patch was applied twice by accident, causing probe failures.
    Revert the accident.
    
    Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
    Fixes: 75fd6485ccce ("usb: phy: generic: Get the vbus supply")
    Cc: stable <stable@kernel.org>
    Reviewed-by: Sean Anderson <sean.anderson@seco.com>
    Link: https://lore.kernel.org/r/20240314092628.1869414-1-alexander.stein@ew.tq-group.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
Revert "x86/mm/ident_map: Use gbpages only where full GB page should be mapped." [+ + +]
Author: Ingo Molnar <mingo@kernel.org>
Date:   Mon Mar 25 11:47:51 2024 +0100

    Revert "x86/mm/ident_map: Use gbpages only where full GB page should be mapped."
    
    commit c567f2948f57bdc03ed03403ae0234085f376b7d upstream.
    
    This reverts commit d794734c9bbfe22f86686dc2909c25f5ffe1a572.
    
    While the original change tries to fix a bug, it also unintentionally broke
    existing systems, see the regressions reported at:
    
      https://lore.kernel.org/all/3a1b9909-45ac-4f97-ad68-d16ef1ce99db@pavinjoseph.com/
    
    Since d794734c9bbf was also marked for -stable, let's back it out before
    causing more damage.
    
    Note that due to another upstream change the revert was not 100% automatic:
    
      0a845e0f6348 mm/treewide: replace pud_large() with pud_leaf()
    
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: <stable@vger.kernel.org>
    Cc: Russ Anderson <rja@hpe.com>
    Cc: Steve Wahl <steve.wahl@hpe.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Link: https://lore.kernel.org/all/3a1b9909-45ac-4f97-ad68-d16ef1ce99db@pavinjoseph.com/
    Fixes: d794734c9bbf ("x86/mm/ident_map: Use gbpages only where full GB page should be mapped.")
    Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ring-buffer: Do not set shortest_full when full target is hit [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Mar 12 11:56:41 2024 -0400

    ring-buffer: Do not set shortest_full when full target is hit
    
    [ Upstream commit 761d9473e27f0c8782895013a3e7b52a37c8bcfc ]
    
    The rb_watermark_hit() checks if the amount of data in the ring buffer is
    above the percentage level passed in by the "full" variable. If it is, it
    returns true.
    
    But it also sets the "shortest_full" field of the cpu_buffer that informs
    writers that it needs to call the irq_work if the amount of data on the
    ring buffer is above the requested amount.
    
    The rb_watermark_hit() always sets the shortest_full even if the amount in
    the ring buffer is what it wants. As it is not going to wait, because it
    has what it wants, there's no reason to set shortest_full.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240312115641.6aa8ba08@gandalf.local.home
    
    Cc: stable@vger.kernel.org
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Fixes: 42fb0a1e84ff5 ("tracing/ring-buffer: Have polling block on watermark")
    Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ring-buffer: Fix full_waiters_pending in poll [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Tue Mar 12 09:19:20 2024 -0400

    ring-buffer: Fix full_waiters_pending in poll
    
    [ Upstream commit 8145f1c35fa648da662078efab299c4467b85ad5 ]
    
    If a reader of the ring buffer is doing a poll, and waiting for the ring
    buffer to hit a specific watermark, there could be a case where it gets
    into an infinite ping-pong loop.
    
    The poll code has:
    
      rbwork->full_waiters_pending = true;
      if (!cpu_buffer->shortest_full ||
          cpu_buffer->shortest_full > full)
             cpu_buffer->shortest_full = full;
    
    The writer will see full_waiters_pending and check if the ring buffer is
    filled over the percentage of the shortest_full value. If it is, it calls
    an irq_work to wake up all the waiters.
    
    But the code could get into a circular loop:
    
            CPU 0                                   CPU 1
            -----                                   -----
     [ Poll ]
       [ shortest_full = 0 ]
       rbwork->full_waiters_pending = true;
                                              if (rbwork->full_waiters_pending &&
                                                  [ buffer percent ] > shortest_full) {
                                                     rbwork->wakeup_full = true;
                                                     [ queue_irqwork ]
    
       cpu_buffer->shortest_full = full;
    
                                              [ IRQ work ]
                                              if (rbwork->wakeup_full) {
                                                    cpu_buffer->shortest_full = 0;
                                                    wakeup poll waiters;
      [woken]
       if ([ buffer percent ] > full)
          break;
       rbwork->full_waiters_pending = true;
                                              if (rbwork->full_waiters_pending &&
                                                  [ buffer percent ] > shortest_full) {
                                                     rbwork->wakeup_full = true;
                                                     [ queue_irqwork ]
    
       cpu_buffer->shortest_full = full;
    
                                              [ IRQ work ]
                                              if (rbwork->wakeup_full) {
                                                    cpu_buffer->shortest_full = 0;
                                                    wakeup poll waiters;
      [woken]
    
     [ Wash, rinse, repeat! ]
    
    In the poll, the shortest_full needs to be set before the
    full_pending_waiters, as once that is set, the writer will compare the
    current shortest_full (which is incorrect) to decide to call the irq_work,
    which will reset the shortest_full (expecting the readers to update it).
    
    Also move the setting of full_waiters_pending after the check if the ring
    buffer has the required percentage filled. There's no reason to tell the
    writer to wake up waiters if there are no waiters.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240312131952.630922155@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Fixes: 42fb0a1e84ff5 ("tracing/ring-buffer: Have polling block on watermark")
    Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ring-buffer: Fix resetting of shortest_full [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Fri Mar 8 15:24:04 2024 -0500

    ring-buffer: Fix resetting of shortest_full
    
    [ Upstream commit 68282dd930ea38b068ce2c109d12405f40df3f93 ]
    
    The "shortest_full" variable is used to keep track of the waiter that is
    waiting for the smallest amount on the ring buffer before being woken up.
    When a tasks waits on the ring buffer, it passes in a "full" value that is
    a percentage. 0 means wake up on any data. 1-100 means wake up from 1% to
    100% full buffer.
    
    As all waiters are on the same wait queue, the wake up happens for the
    waiter with the smallest percentage.
    
    The problem is that the smallest_full on the cpu_buffer that stores the
    smallest amount doesn't get reset when all the waiters are woken up. It
    does get reset when the ring buffer is reset (echo > /sys/kernel/tracing/trace).
    
    This means that tasks may be woken up more often then when they want to
    be. Instead, have the shortest_full field get reset just before waking up
    all the tasks. If the tasks wait again, they will update the shortest_full
    before sleeping.
    
    Also add locking around setting of shortest_full in the poll logic, and
    change "work" to "rbwork" to match the variable name for rb_irq_work
    structures that are used in other places.
    
    Link: https://lore.kernel.org/linux-trace-kernel/20240308202431.948914369@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: linke li <lilinke99@qq.com>
    Cc: Rabin Vincent <rabin@rab.in>
    Fixes: 2c2b0a78b3739 ("ring-buffer: Add percentage of ring buffer full to wake up reader")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Stable-dep-of: 8145f1c35fa6 ("ring-buffer: Fix full_waiters_pending in poll")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ring-buffer: Fix waking up ring buffer readers [+ + +]
Author: Steven Rostedt (Google) <rostedt@goodmis.org>
Date:   Fri Mar 8 15:24:03 2024 -0500

    ring-buffer: Fix waking up ring buffer readers
    
    [ Upstream commit b3594573681b53316ec0365332681a30463edfd6 ]
    
    A task can wait on a ring buffer for when it fills up to a specific
    watermark. The writer will check the minimum watermark that waiters are
    waiting for and if the ring buffer is past that, it will wake up all the
    waiters.
    
    The waiters are in a wait loop, and will first check if a signal is
    pending and then check if the ring buffer is at the desired level where it
    should break out of the loop.
    
    If a file that uses a ring buffer closes, and there's threads waiting on
    the ring buffer, it needs to wake up those threads. To do this, a
    "wait_index" was used.
    
    Before entering the wait loop, the waiter will read the wait_index. On
    wakeup, it will check if the wait_index is different than when it entered
    the loop, and will exit the loop if it is. The waker will only need to
    update the wait_index before waking up the waiters.
    
    This had a couple of bugs. One trivial one and one broken by design.
    
    The trivial bug was that the waiter checked the wait_index after the
    schedule() call. It had to be checked between the prepare_to_wait() and
    the schedule() which it was not.
    
    The main bug is that the first check to set the default wait_index will
    always be outside the prepare_to_wait() and the schedule(). That's because
    the ring_buffer_wait() doesn't have enough context to know if it should
    break out of the loop.
    
    The loop itself is not needed, because all the callers to the
    ring_buffer_wait() also has their own loop, as the callers have a better
    sense of what the context is to decide whether to break out of the loop
    or not.
    
    Just have the ring_buffer_wait() block once, and if it gets woken up, exit
    the function and let the callers decide what to do next.
    
    Link: https://lore.kernel.org/all/CAHk-=whs5MdtNjzFkTyaUy=vHi=qwWgPi0JgTe6OYUYMNSRZfg@mail.gmail.com/
    Link: https://lore.kernel.org/linux-trace-kernel/20240308202431.792933613@goodmis.org
    
    Cc: stable@vger.kernel.org
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mark Rutland <mark.rutland@arm.com>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: linke li <lilinke99@qq.com>
    Cc: Rabin Vincent <rabin@rab.in>
    Fixes: e30f53aad2202 ("tracing: Do not busy wait in buffer splice")
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Stable-dep-of: 761d9473e27f ("ring-buffer: Do not set shortest_full when full target is hit")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ring-buffer: use READ_ONCE() to read cpu_buffer->commit_page in concurrent environment [+ + +]
Author: linke li <lilinke99@qq.com>
Date:   Sat Mar 2 12:42:21 2024 +0800

    ring-buffer: use READ_ONCE() to read cpu_buffer->commit_page in concurrent environment
    
    [ Upstream commit f1e30cb6369251c03f63c564006f96a54197dcc4 ]
    
    In function ring_buffer_iter_empty(), cpu_buffer->commit_page is read
    while other threads may change it. It may cause the time_stamp that read
    in the next line come from a different page. Use READ_ONCE() to avoid
    having to reason about compiler optimizations now and in future.
    
    Link: https://lore.kernel.org/linux-trace-kernel/tencent_DFF7D3561A0686B5E8FC079150A02505180A@qq.com
    
    Cc: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: linke li <lilinke99@qq.com>
    Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
riscv: Fix spurious errors from __get/put_kernel_nofault [+ + +]
Author: Samuel Holland <samuel.holland@sifive.com>
Date:   Mon Mar 11 19:19:13 2024 -0700

    riscv: Fix spurious errors from __get/put_kernel_nofault
    
    commit d080a08b06b6266cc3e0e86c5acfd80db937cb6b upstream.
    
    These macros did not initialize __kr_err, so they could fail even if
    the access did not fault.
    
    Cc: stable@vger.kernel.org
    Fixes: d464118cdc41 ("riscv: implement __get_kernel_nofault and __put_user_nofault")
    Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
    Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
    Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
    Link: https://lore.kernel.org/r/20240312022030.320789-1-samuel.holland@sifive.com
    Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/entry: align system call table on 8 bytes [+ + +]
Author: Sumanth Korikkar <sumanthk@linux.ibm.com>
Date:   Tue Mar 26 18:12:13 2024 +0100

    s390/entry: align system call table on 8 bytes
    
    commit 378ca2d2ad410a1cd5690d06b46c5e2297f4c8c0 upstream.
    
    Align system call table on 8 bytes. With sys_call_table entry size
    of 8 bytes that eliminates the possibility of a system call pointer
    crossing cache line boundary.
    
    Cc: stable@kernel.org
    Suggested-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
    Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
    Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
s390/zcrypt: fix reference counting on zcrypt card objects [+ + +]
Author: Harald Freudenberger <freude@linux.ibm.com>
Date:   Thu Feb 29 15:20:09 2024 +0100

    s390/zcrypt: fix reference counting on zcrypt card objects
    
    [ Upstream commit 50ed48c80fecbe17218afed4f8bed005c802976c ]
    
    Tests with hot-plugging crytpo cards on KVM guests with debug
    kernel build revealed an use after free for the load field of
    the struct zcrypt_card. The reason was an incorrect reference
    handling of the zcrypt card object which could lead to a free
    of the zcrypt card object while it was still in use.
    
    This is an example of the slab message:
    
        kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b
        kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43
        kernel:  kmalloc_trace+0x3f2/0x470
        kernel:  zcrypt_card_alloc+0x36/0x70 [zcrypt]
        kernel:  zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]
        kernel:  ap_device_probe+0x15c/0x290
        kernel:  really_probe+0xd2/0x468
        kernel:  driver_probe_device+0x40/0xf0
        kernel:  __device_attach_driver+0xc0/0x140
        kernel:  bus_for_each_drv+0x8c/0xd0
        kernel:  __device_attach+0x114/0x198
        kernel:  bus_probe_device+0xb4/0xc8
        kernel:  device_add+0x4d2/0x6e0
        kernel:  ap_scan_adapter+0x3d0/0x7c0
        kernel:  ap_scan_bus+0x5a/0x3b0
        kernel:  ap_scan_bus_wq_callback+0x40/0x60
        kernel:  process_one_work+0x26e/0x620
        kernel:  worker_thread+0x21c/0x440
        kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43
        kernel:  kfree+0x37e/0x418
        kernel:  zcrypt_card_put+0x54/0x80 [zcrypt]
        kernel:  ap_device_remove+0x4c/0xe0
        kernel:  device_release_driver_internal+0x1c4/0x270
        kernel:  bus_remove_device+0x100/0x188
        kernel:  device_del+0x164/0x3c0
        kernel:  device_unregister+0x30/0x90
        kernel:  ap_scan_adapter+0xc8/0x7c0
        kernel:  ap_scan_bus+0x5a/0x3b0
        kernel:  ap_scan_bus_wq_callback+0x40/0x60
        kernel:  process_one_work+0x26e/0x620
        kernel:  worker_thread+0x21c/0x440
        kernel:  kthread+0x150/0x168
        kernel:  __ret_from_fork+0x3c/0x58
        kernel:  ret_from_fork+0xa/0x30
        kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)
        kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88
        kernel: Redzone  00000000885a74b0: bb bb bb bb bb bb bb bb                          ........
        kernel: Object   00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
        kernel: Object   00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
        kernel: Object   00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
        kernel: Object   00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
        kernel: Object   00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
        kernel: Object   00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5  kkkkkkkkkkhKkkk.
        kernel: Redzone  00000000885a7518: bb bb bb bb bb bb bb bb                          ........
        kernel: Padding  00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ
        kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2
        kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)
        kernel: Call Trace:
        kernel:  [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120
        kernel:  [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140
        kernel:  [<00000000c99d53cc>] check_object+0x334/0x3f8
        kernel:  [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8
        kernel:  [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0
        kernel:  [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8
        kernel:  [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8
        kernel:  [<00000000c99dc8dc>] __kmalloc+0x434/0x590
        kernel:  [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0
        kernel:  [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0
        kernel:  [<00000000c9b919dc>] ext4_htree_fill_tree+0x134/0x400
        kernel:  [<00000000c9b4b3d0>] ext4_dx_readdir+0x160/0x2f0
        kernel:  [<00000000c9b4bedc>] ext4_readdir+0x5f4/0x760
        kernel:  [<00000000c9a7efc4>] iterate_dir+0xb4/0x280
        kernel:  [<00000000c9a7f1ea>] __do_sys_getdents64+0x5a/0x120
        kernel:  [<00000000ca5d6946>] __do_syscall+0x256/0x310
        kernel:  [<00000000ca5eea10>] system_call+0x70/0x98
        kernel: INFO: lockdep is turned off.
        kernel: FIX kmalloc-96: Restoring Poison 0x00000000885a7512-0x00000000885a7513=0x6b
        kernel: FIX kmalloc-96: Marking all objects used
    
    The fix is simple: Before use of the queue not only the queue object
    but also the card object needs to increase it's reference count
    with a call to zcrypt_card_get(). Similar after use of the queue
    not only the queue but also the card object's reference count is
    decreased with zcrypt_card_put().
    
    Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
    Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
scripts: kernel-doc: Fix syntax error due to undeclared args variable [+ + +]
Author: Salvatore Bonaccorso <carnil@debian.org>
Date:   Mon Mar 4 22:24:12 2024 +0100

    scripts: kernel-doc: Fix syntax error due to undeclared args variable
    
    The backport of commit 3080ea5553cc ("stddef: Introduce
    DECLARE_FLEX_ARRAY() helper") to 5.10.y (as a prerequisite of another
    fix) modified scripts/kernel-doc and introduced a syntax error:
    
    Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.
    Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.
    Execution of ./scripts/kernel-doc aborted due to compilation errors.
    
    Note: The issue could be fixed in the 5.10.y series as well by
    backporting e86bdb24375a ("scripts: kernel-doc: reduce repeated regex
    expressions into variables") but just replacing the undeclared args back
    to ([^,)]+) was the most straightforward approach. The issue is specific
    to the backport to the 5.10.y series. Thus there is as well no upstream
    commit for this change.
    
    Fixes: 443b16ee3d9c ("stddef: Introduce DECLARE_FLEX_ARRAY() helper") # 5.10.y
    Reported-by: Ben Hutchings <ben@decadent.org.uk>
    Link: https://lore.kernel.org/regressions/ZeHKjjPGoyv_b2Tg@eldamar.lan/T/#u
    Link: https://bugs.debian.org/1064035
    Signed-off-by: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
scsi: core: Fix unremoved procfs host directory regression [+ + +]
Author: Guilherme G. Piccoli <gpiccoli@igalia.com>
Date:   Wed Mar 13 08:21:20 2024 -0300

    scsi: core: Fix unremoved procfs host directory regression
    
    commit f23a4d6e07570826fe95023ca1aa96a011fa9f84 upstream.
    
    Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name}
    directory earlier") fixed a bug related to modules loading/unloading, by
    adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led
    to a potential duplicate call to the hostdir_rm() routine, since it's also
    called from scsi_host_dev_release(). That triggered a regression report,
    which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host
    directory removal regression"). The fix just dropped the hostdir_rm() call
    from dev_release().
    
    But it happens that this proc directory is created on scsi_host_alloc(),
    and that function "pairs" with scsi_host_dev_release(), while
    scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the
    reason for removing the proc directory on dev_release() was meant to cover
    cases in which a SCSI host structure was allocated, but the call to
    scsi_add_host() didn't happen. And that pattern happens to exist in some
    error paths, for example.
    
    Syzkaller causes that by using USB raw gadget device, error'ing on
    usb-storage driver, at usb_stor_probe2(). By checking that path, we can see
    that the BadDevice label leads to a scsi_host_put() after a SCSI host
    allocation, but there's no call to scsi_add_host() in such path. That leads
    to messages like this in dmesg (and a leak of the SCSI host proc
    structure):
    
    usb-storage 4-1:87.51: USB Mass Storage device detected
    proc_dir_entry 'scsi/usb-storage' already registered
    WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376
    
    The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),
    but guard that with the state check for SHOST_CREATED; there is even a
    comment in scsi_host_dev_release() detailing that: such conditional is
    meant for cases where the SCSI host was allocated but there was no calls to
    {add,remove}_host(), like the usb-storage case.
    
    This is what we propose here and with that, the error path of usb-storage
    does not trigger the warning anymore.
    
    Reported-by: syzbot+c645abf505ed21f931b5@syzkaller.appspotmail.com
    Fixes: be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression")
    Cc: stable@vger.kernel.org
    Cc: Bart Van Assche <bvanassche@acm.org>
    Cc: John Garry <john.g.garry@oracle.com>
    Cc: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
    Link: https://lore.kernel.org/r/20240313113006.2834799-1-gpiccoli@igalia.com
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: lpfc: Correct size for wqe for memset() [+ + +]
Author: Muhammad Usama Anjum <usama.anjum@collabora.com>
Date:   Mon Mar 4 14:06:48 2024 +0500

    scsi: lpfc: Correct size for wqe for memset()
    
    commit 28d41991182c210ec1654f8af2e140ef4cc73f20 upstream.
    
    The wqe is of type lpfc_wqe128. It should be memset with the same type.
    
    Fixes: 6c621a2229b0 ("scsi: lpfc: Separate NVMET RQ buffer posting from IO resources SGL/iocbq/context")
    Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Link: https://lore.kernel.org/r/20240304090649.833953-1-usama.anjum@collabora.com
    Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
    Reviewed-by: Justin Tee <justintee8345@gmail.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc() [+ + +]
Author: Justin Tee <justin.tee@broadcom.com>
Date:   Wed Jan 31 10:50:57 2024 -0800

    scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()
    
    [ Upstream commit 2ae917d4bcab80ab304b774d492e2fcd6c52c06b ]
    
    The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an
    unsuccessful status.  In such cases, the elsiocb is not issued, the
    completion is not called, and thus the elsiocb resource is leaked.
    
    Check return value after calling lpfc_sli4_resume_rpi() and conditionally
    release the elsiocb resource.
    
    Signed-off-by: Justin Tee <justin.tee@broadcom.com>
    Link: https://lore.kernel.org/r/20240131185112.149731-3-justintee8345@gmail.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: mylex: Fix sysfs buffer lengths [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Tue Mar 26 23:38:06 2024 +0100

    scsi: mylex: Fix sysfs buffer lengths
    
    [ Upstream commit 1197c5b2099f716b3de327437fb50900a0b936c9 ]
    
    The myrb and myrs drivers use an odd way of implementing their sysfs files,
    calling snprintf() with a fixed length of 32 bytes to print into a page
    sized buffer. One of the strings is actually longer than 32 bytes, which
    clang can warn about:
    
    drivers/scsi/myrb.c:1906:10: error: 'snprintf' will always be truncated; specified size is 32, but format string expands to at least 34 [-Werror,-Wformat-truncation]
    drivers/scsi/myrs.c:1089:10: error: 'snprintf' will always be truncated; specified size is 32, but format string expands to at least 34 [-Werror,-Wformat-truncation]
    
    These could all be plain sprintf() without a length as the buffer is always
    long enough. On the other hand, sysfs files should not be overly long
    either, so just double the length to make sure the longest strings don't
    get truncated here.
    
    Fixes: 77266186397c ("scsi: myrs: Add Mylex RAID controller (SCSI interface)")
    Fixes: 081ff398c56c ("scsi: myrb: Add Mylex RAID controller (block interface)")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Link: https://lore.kernel.org/r/20240326223825.4084412-8-arnd@kernel.org
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: Delay I/O Abort on PCI error [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Feb 27 22:11:26 2024 +0530

    scsi: qla2xxx: Delay I/O Abort on PCI error
    
    commit 591c1fdf2016d118b8fbde427b796fac13f3f070 upstream.
    
    Currently when PCI error is detected, I/O is aborted manually through the
    ABORT IOCB mechanism which is not guaranteed to succeed.
    
    Instead, wait for the OS or system to notify driver to wind down I/O
    through the pci_error_handlers api.  Set eeh_busy flag to pause all traffic
    and wait for I/O to drain.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20240227164127.36465-11-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Fix command flush on cable pull [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Feb 27 22:11:22 2024 +0530

    scsi: qla2xxx: Fix command flush on cable pull
    
    commit a27d4d0e7de305def8a5098a614053be208d1aa1 upstream.
    
    System crash due to command failed to flush back to SCSI layer.
    
     BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
     PGD 0 P4D 0
     Oops: 0000 [#1] SMP NOPTI
     CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-372.9.1.el8.x86_64 #1
     Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021
     Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]
     RIP: 0010:__wake_up_common+0x4c/0x190
     Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75
     RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086
     RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000
     RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320
     RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8
     R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20
     R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
     FS:  0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0
     DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
     DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
     PKRU: 55555554
     Call Trace:
      __wake_up_common_lock+0x7c/0xc0
      qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]
     qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0
     ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]
     qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200.
      ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]
     qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1
     ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]
     qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0
      ? __switch_to+0x10c/0x450
     ? process_one_work+0x1a7/0x360
     qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201.
      ? worker_thread+0x1ce/0x390
      ? create_worker+0x1a0/0x1a0
     qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70
      ? kthread+0x10a/0x120
     qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8
      ? set_kthread_struct+0x40/0x40
     qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed.
      ? ret_from_fork+0x1f/0x40
     qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout
    
    The system was under memory stress where driver was not able to allocate an
    SRB to carry out error recovery of cable pull.  The failure to flush causes
    upper layer to start modifying scsi_cmnd.  When the system frees up some
    memory, the subsequent cable pull trigger another command flush. At this
    point the driver access a null pointer when attempting to DMA unmap the
    SGL.
    
    Add a check to make sure commands are flush back on session tear down to
    prevent the null pointer access.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20240227164127.36465-7-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Split FCE|EFT trace control [+ + +]
Author: Quinn Tran <qutran@marvell.com>
Date:   Tue Feb 27 22:11:19 2024 +0530

    scsi: qla2xxx: Split FCE|EFT trace control
    
    commit 76a192e1a566e15365704b9f8fb3b70825f85064 upstream.
    
    Current code combines the allocation of FCE|EFT trace buffers and enables
    the features all in 1 step.
    
    Split this step into separate steps in preparation for follow-on patch to
    allow user to have a choice to enable / disable FCE trace feature.
    
    Cc: stable@vger.kernel.org
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Quinn Tran <qutran@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20240227164127.36465-4-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

scsi: qla2xxx: Update manufacturer detail [+ + +]
Author: Bikash Hazarika <bhazarika@marvell.com>
Date:   Tue Feb 27 22:11:20 2024 +0530

    scsi: qla2xxx: Update manufacturer detail
    
    [ Upstream commit 688fa069fda6fce24d243cddfe0c7024428acb74 ]
    
    Update manufacturer detail from "Marvell Semiconductor, Inc." to
    "Marvell".
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Bikash Hazarika <bhazarika@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Link: https://lore.kernel.org/r/20240227164127.36465-5-njavali@marvell.com
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: qla2xxx: Update manufacturer details [+ + +]
Author: Bikash Hazarika <bhazarika@marvell.com>
Date:   Tue Jul 12 22:20:44 2022 -0700

    scsi: qla2xxx: Update manufacturer details
    
    [ Upstream commit 1ccad27716ecad1fd58c35e579bedb81fa5e1ad5 ]
    
    Update manufacturer details to indicate Marvell Semiconductors.
    
    Link: https://lore.kernel.org/r/20220713052045.10683-10-njavali@marvell.com
    Cc: stable@vger.kernel.org
    Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
    Signed-off-by: Bikash Hazarika <bhazarika@marvell.com>
    Signed-off-by: Nilesh Javali <njavali@marvell.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Stable-dep-of: 688fa069fda6 ("scsi: qla2xxx: Update manufacturer detail")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

scsi: sd: Fix wrong zone_write_granularity value during revalidate [+ + +]
Author: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Date:   Mon Mar 6 15:30:24 2023 +0900

    scsi: sd: Fix wrong zone_write_granularity value during revalidate
    
    commit 288b3271d920c9ba949c3bab0f749f4cecc70e09 upstream.
    
    When the sd driver revalidates host-managed SMR disks, it calls
    disk_set_zoned() which changes the zone_write_granularity attribute value
    to the logical block size regardless of the device type. After that, the sd
    driver overwrites the value in sd_zbc_read_zone() with the physical block
    size, since ZBC/ZAC requires this for host-managed disks. Between the calls
    to disk_set_zoned() and sd_zbc_read_zone(), there exists a window where the
    attribute shows the logical block size as the zone_write_granularity value,
    which is wrong for host-managed disks. The duration of the window is from
    20ms to 200ms, depending on report zone command execution time.
    
    To avoid the wrong zone_write_granularity value between disk_set_zoned()
    and sd_zbc_read_zone(), modify the value not in sd_zbc_read_zone() but
    just after disk_set_zoned() call.
    
    Fixes: a805a4fa4fa3 ("block: introduce zone_write_granularity limit")
    Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
    Link: https://lore.kernel.org/r/20230306063024.3376959-1-shinichiro.kawasaki@wdc.com
    Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
selftests/mqueue: Set timeout to 180 seconds [+ + +]
Author: SeongJae Park <sj@kernel.org>
Date:   Mon Feb 19 16:08:02 2024 -0800

    selftests/mqueue: Set timeout to 180 seconds
    
    [ Upstream commit 85506aca2eb4ea41223c91c5fe25125953c19b13 ]
    
    While mq_perf_tests runs with the default kselftest timeout limit, which
    is 45 seconds, the test takes about 60 seconds to complete on i3.metal
    AWS instances.  Hence, the test always times out.  Increase the timeout
    to 180 seconds.
    
    Fixes: 852c8cbf34d3 ("selftests/kselftest/runner.sh: Add 45 second timeout per test")
    Cc: <stable@vger.kernel.org> # 5.4.x
    Signed-off-by: SeongJae Park <sj@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
selftests: reuseaddr_conflict: add missing new line at the end of the output [+ + +]
Author: Jakub Kicinski <kuba@kernel.org>
Date:   Fri Mar 29 09:05:59 2024 -0700

    selftests: reuseaddr_conflict: add missing new line at the end of the output
    
    commit 31974122cfdeaf56abc18d8ab740d580d9833e90 upstream.
    
    The netdev CI runs in a VM and captures serial, so stdout and
    stderr get combined. Because there's a missing new line in
    stderr the test ends up corrupting KTAP:
    
      # Successok 1 selftests: net: reuseaddr_conflict
    
    which should have been:
    
      # Success
      ok 1 selftests: net: reuseaddr_conflict
    
    Fixes: 422d8dc6fd3a ("selftest: add a reuseaddr test")
    Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
    Link: https://lore.kernel.org/r/20240329160559.249476-1-kuba@kernel.org
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
serial: Lock console when calling into driver before registration [+ + +]
Author: Peter Collingbourne <pcc@google.com>
Date:   Mon Mar 4 13:43:49 2024 -0800

    serial: Lock console when calling into driver before registration
    
    [ Upstream commit 801410b26a0e8b8a16f7915b2b55c9528b69ca87 ]
    
    During the handoff from earlycon to the real console driver, we have
    two separate drivers operating on the same device concurrently. In the
    case of the 8250 driver these concurrent accesses cause problems due
    to the driver's use of banked registers, controlled by LCR.DLAB. It is
    possible for the setup(), config_port(), pm() and set_mctrl() callbacks
    to set DLAB, which can cause the earlycon code that intends to access
    TX to instead access DLL, leading to missed output and corruption on
    the serial line due to unintended modifications to the baud rate.
    
    In particular, for setup() we have:
    
    univ8250_console_setup()
    -> serial8250_console_setup()
    -> uart_set_options()
    -> serial8250_set_termios()
    -> serial8250_do_set_termios()
    -> serial8250_do_set_divisor()
    
    For config_port() we have:
    
    serial8250_config_port()
    -> autoconfig()
    
    For pm() we have:
    
    serial8250_pm()
    -> serial8250_do_pm()
    -> serial8250_set_sleep()
    
    For set_mctrl() we have (for some devices):
    
    serial8250_set_mctrl()
    -> omap8250_set_mctrl()
    -> __omap8250_set_mctrl()
    
    To avoid such problems, let's make it so that the console is locked
    during pre-registration calls to these callbacks, which will prevent
    the earlycon driver from running concurrently.
    
    Remove the partial solution to this problem in the 8250 driver
    that locked the console only during autoconfig_irq(), as this would
    result in a deadlock with the new approach. The console continues
    to be locked during autoconfig_irq() because it can only be called
    through uart_configure_port().
    
    Although this patch introduces more locking than strictly necessary
    (and in particular it also locks during the call to rs485_config()
    which is not affected by this issue as far as I can tell), it follows
    the principle that it is the responsibility of the generic console
    code to manage the earlycon handoff by ensuring that earlycon and real
    console driver code cannot run concurrently, and not the individual
    drivers.
    
    Signed-off-by: Peter Collingbourne <pcc@google.com>
    Reviewed-by: John Ogness <john.ogness@linutronix.de>
    Link: https://linux-review.googlesource.com/id/I7cf8124dcebf8618e6b2ee543fa5b25532de55d8
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240304214350.501253-1-pcc@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: max310x: fix NULL pointer dereference in I2C instantiation [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Thu Jan 18 10:21:57 2024 -0500

    serial: max310x: fix NULL pointer dereference in I2C instantiation
    
    [ Upstream commit 0d27056c24efd3d63a03f3edfbcfc4827086b110 ]
    
    When trying to instantiate a max14830 device from userspace:
    
        echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device
    
    we get the following error:
    
        Unable to handle kernel NULL pointer dereference at virtual address...
        ...
        Call trace:
            max310x_i2c_probe+0x48/0x170 [max310x]
            i2c_device_probe+0x150/0x2a0
        ...
    
    Add check for validity of devtype to prevent the error, and abort probe
    with a meaningful error message.
    
    Fixes: 2e1f2d9a9bdb ("serial: max310x: implement I2C support")
    Cc: stable@vger.kernel.org
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20240118152213.2644269-2-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Mon Dec 11 12:13:52 2023 -0500

    serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO
    
    commit dbf4ab821804df071c8b566d9813083125e6d97b upstream.
    
    The SC16IS7XX IC supports a burst mode to access the FIFOs where the
    initial register address is sent ($00), followed by all the FIFO data
    without having to resend the register address each time. In this mode, the
    IC doesn't increment the register address for each R/W byte.
    
    The regmap_raw_read() and regmap_raw_write() are functions which can
    perform IO over multiple registers. They are currently used to read/write
    from/to the FIFO, and although they operate correctly in this burst mode on
    the SPI bus, they would corrupt the regmap cache if it was not disabled
    manually. The reason is that when the R/W size is more than 1 byte, these
    functions assume that the register address is incremented and handle the
    cache accordingly.
    
    Convert FIFO R/W functions to use the regmap _noinc_ versions in order to
    remove the manual cache control which was a workaround when using the
    _raw_ versions. FIFO registers are properly declared as volatile so
    cache will not be used/updated for FIFO accesses.
    
    Fixes: dfeae619d781 ("serial: sc16is7xx")
    Cc:  <stable@vger.kernel.org>
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20231211171353.2901416-6-hugo@hugovil.com
    Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Signed-off-by: GONG, Ruiqi <gongruiqi1@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
slimbus: core: Remove usage of the deprecated ida_simple_xx() API [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Sat Feb 24 11:41:37 2024 +0000

    slimbus: core: Remove usage of the deprecated ida_simple_xx() API
    
    [ Upstream commit 89ffa4cccec54467446f141a79b9e36893079fb8 ]
    
    ida_alloc() and ida_free() should be preferred to the deprecated
    ida_simple_get() and ida_simple_remove().
    
    Note that the upper limit of ida_simple_get() is exclusive, but the one of
    ida_alloc_range() is inclusive. So change this change allows one more
    device. Previously address 0xFE was never used.
    
    Fixes: 46a2bb5a7f7e ("slimbus: core: Add slim controllers support")
    Cc: Stable@vger.kernel.org
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Link: https://lore.kernel.org/r/20240224114137.85781-2-srinivas.kandagatla@linaro.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
smack: Handle SMACK64TRANSMUTE in smack_inode_setsecurity() [+ + +]
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date:   Thu Nov 16 10:01:22 2023 +0100

    smack: Handle SMACK64TRANSMUTE in smack_inode_setsecurity()
    
    [ Upstream commit ac02f007d64eb2769d0bde742aac4d7a5fc6e8a5 ]
    
    If the SMACK64TRANSMUTE xattr is provided, and the inode is a directory,
    update the in-memory inode flags by setting SMK_INODE_TRANSMUTE.
    
    Cc: stable@vger.kernel.org
    Fixes: 5c6d1125f8db ("Smack: Transmute labels on specified directories") # v2.6.38.x
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

smack: Set SMACK64TRANSMUTE only for dirs in smack_inode_setxattr() [+ + +]
Author: Roberto Sassu <roberto.sassu@huawei.com>
Date:   Thu Nov 16 10:01:21 2023 +0100

    smack: Set SMACK64TRANSMUTE only for dirs in smack_inode_setxattr()
    
    [ Upstream commit 9c82169208dde516510aaba6bbd8b13976690c5d ]
    
    Since the SMACK64TRANSMUTE xattr makes sense only for directories, enforce
    this restriction in smack_inode_setxattr().
    
    Cc: stable@vger.kernel.org
    Fixes: 5c6d1125f8db ("Smack: Transmute labels on specified directories") # v2.6.38.x
    Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
    Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
soc: fsl: qbman: Add CGR update function [+ + +]
Author: Sean Anderson <sean.anderson@seco.com>
Date:   Fri Sep 2 17:57:35 2022 -0400

    soc: fsl: qbman: Add CGR update function
    
    [ Upstream commit 914f8b228ede709274b8c80514b352248ec9da00 ]
    
    This adds a function to update a CGR with new parameters. qman_create_cgr
    can almost be used for this (with flags=0), but it's not suitable because
    it also registers the callback function. The _safe variant was modeled off
    of qman_cgr_delete_safe. However, we handle multiple arguments and a return
    value.
    
    Signed-off-by: Sean Anderson <sean.anderson@seco.com>
    Acked-by: Camelia Groza <camelia.groza@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: fbec4e7fed89 ("soc: fsl: qbman: Use raw spinlock for cgr_lock")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: fsl: qbman: Add helper for sanity checking cgr ops [+ + +]
Author: Sean Anderson <sean.anderson@seco.com>
Date:   Fri Sep 2 17:57:34 2022 -0400

    soc: fsl: qbman: Add helper for sanity checking cgr ops
    
    [ Upstream commit d0e17a4653cebc2c8a20251c837dd1fcec5014d9 ]
    
    This breaks out/combines get_affine_portal and the cgr sanity check in
    preparation for the next commit. No functional change intended.
    
    Signed-off-by: Sean Anderson <sean.anderson@seco.com>
    Acked-by: Camelia Groza <camelia.groza@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: fbec4e7fed89 ("soc: fsl: qbman: Use raw spinlock for cgr_lock")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: fsl: qbman: Always disable interrupts when taking cgr_lock [+ + +]
Author: Sean Anderson <sean.anderson@linux.dev>
Date:   Mon Mar 11 12:38:29 2024 -0400

    soc: fsl: qbman: Always disable interrupts when taking cgr_lock
    
    [ Upstream commit 584c2a9184a33a40fceee838f856de3cffa19be3 ]
    
    smp_call_function_single disables IRQs when executing the callback. To
    prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
    This is already done by qman_update_cgr and qman_delete_cgr; fix the
    other lockers.
    
    Fixes: 96f413f47677 ("soc/fsl/qbman: fix issue in qman_delete_cgr_safe()")
    CC: stable@vger.kernel.org
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
    Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

soc: fsl: qbman: Use raw spinlock for cgr_lock [+ + +]
Author: Sean Anderson <sean.anderson@linux.dev>
Date:   Mon Mar 11 12:38:30 2024 -0400

    soc: fsl: qbman: Use raw spinlock for cgr_lock
    
    [ Upstream commit fbec4e7fed89b579f2483041fabf9650fb0dd6bc ]
    
    smp_call_function always runs its callback in hard IRQ context, even on
    PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock
    for cgr_lock to ensure we aren't waiting on a sleeping task.
    
    Although this bug has existed for a while, it was not apparent until
    commit ef2a8d5478b9 ("net: dpaa: Adjust queue depth on rate change")
    which invokes smp_call_function_single via qman_update_cgr_safe every
    time a link goes up or down.
    
    Fixes: 96f413f47677 ("soc/fsl/qbman: fix issue in qman_delete_cgr_safe()")
    CC: stable@vger.kernel.org
    Reported-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Closes: https://lore.kernel.org/all/20230323153935.nofnjucqjqnz34ej@skbuf/
    Reported-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
    Closes: https://lore.kernel.org/linux-arm-kernel/87wmsyvclu.fsf@pengutronix.de/
    Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
    Reviewed-by: Camelia Groza <camelia.groza@nxp.com>
    Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sparc64: NMI watchdog: fix return value of __setup handler [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Feb 10 21:28:02 2024 -0800

    sparc64: NMI watchdog: fix return value of __setup handler
    
    [ Upstream commit 3ed7c61e49d65dacb96db798c0ab6fcd55a1f20f ]
    
    __setup() handlers should return 1 to obsolete_checksetup() in
    init/main.c to indicate that the boot option has been handled.
    A return of 0 causes the boot option/value to be listed as an Unknown
    kernel parameter and added to init's (limited) argument or environment
    strings. Also, error return codes don't mean anything to
    obsolete_checksetup() -- only non-zero (usually 1) or zero.
    So return 1 from setup_nmi_watchdog().
    
    Fixes: e5553a6d0442 ("sparc64: Implement NMI watchdog on capable cpus.")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: Igor Zhbanov <izh1979@gmail.com>
    Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: sparclinux@vger.kernel.org
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: stable@vger.kernel.org
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: Andreas Larsson <andreas@gaisler.com>
    Link: https://lore.kernel.org/r/20240211052802.22612-1-rdunlap@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sparc: vDSO: fix return value of __setup handler [+ + +]
Author: Randy Dunlap <rdunlap@infradead.org>
Date:   Sat Feb 10 21:28:08 2024 -0800

    sparc: vDSO: fix return value of __setup handler
    
    [ Upstream commit 5378f00c935bebb846b1fdb0e79cb76c137c56b5 ]
    
    __setup() handlers should return 1 to obsolete_checksetup() in
    init/main.c to indicate that the boot option has been handled.
    A return of 0 causes the boot option/value to be listed as an Unknown
    kernel parameter and added to init's (limited) argument or environment
    strings. Also, error return codes don't mean anything to
    obsolete_checksetup() -- only non-zero (usually 1) or zero.
    So return 1 from vdso_setup().
    
    Fixes: 9a08862a5d2e ("vDSO for sparc")
    Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
    Reported-by: Igor Zhbanov <izh1979@gmail.com>
    Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: sparclinux@vger.kernel.org
    Cc: Dan Carpenter <dan.carpenter@oracle.com>
    Cc: Nick Alcock <nick.alcock@oracle.com>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: stable@vger.kernel.org
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Andreas Larsson <andreas@gaisler.com>
    Signed-off-by: Andreas Larsson <andreas@gaisler.com>
    Link: https://lore.kernel.org/r/20240211052808.22635-1-rdunlap@infradead.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
speakup: Fix 8bit characters from direct synth [+ + +]
Author: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date:   Sun Feb 4 16:57:36 2024 +0100

    speakup: Fix 8bit characters from direct synth
    
    [ Upstream commit b6c8dafc9d86eb77e502bb018ec4105e8d2fbf78 ]
    
    When userland echoes 8bit characters to /dev/synth with e.g.
    
    echo -e '\xe9' > /dev/synth
    
    synth_write would get characters beyond 0x7f, and thus negative when
    char is signed.  When given to synth_buffer_add which takes a u16, this
    would sign-extend and produce a U+ffxy character rather than U+xy.
    Users thus get garbled text instead of accents in their output.
    
    Let's fix this by making sure that we read unsigned characters.
    
    Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
    Fixes: 89fc2ae80bb1 ("speakup: extend synth buffer to 16bit unicode characters")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20240204155736.2oh4ot7tiaa2wpbh@begin
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
staging: vc04_services: changen strncpy() to strscpy_pad() [+ + +]
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Wed Mar 13 17:36:56 2024 +0100

    staging: vc04_services: changen strncpy() to strscpy_pad()
    
    commit ef25725b7f8aaffd7756974d3246ec44fae0a5cf upstream.
    
    gcc-14 warns about this strncpy() that results in a non-terminated
    string for an overflow:
    
    In file included from include/linux/string.h:369,
                     from drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c:20:
    In function 'strncpy',
        inlined from 'create_component' at drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c:940:2:
    include/linux/fortify-string.h:108:33: error: '__builtin_strncpy' specified bound 128 equals destination size [-Werror=stringop-truncation]
    
    Change it to strscpy_pad(), which produces a properly terminated and
    zero-padded string.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/20240313163712.224585-1-arnd@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: vc04_services: fix information leak in create_component() [+ + +]
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date:   Wed Mar 13 21:07:43 2024 +0300

    staging: vc04_services: fix information leak in create_component()
    
    commit f37e76abd614b68987abc8e5c22d986013349771 upstream.
    
    The m.u.component_create.pid field is for debugging and in the mainline
    kernel it's not used anything.  However, it still needs to be set to
    something to prevent disclosing uninitialized stack data.  Set it to
    zero.
    
    Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera driver.")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/2d972847-9ebd-481b-b6f9-af390f5aabd3@moroto.mountain
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
SUNRPC: increase size of rpc_wait_queue.qlen from unsigned short to unsigned int [+ + +]
Author: Dai Ngo <dai.ngo@oracle.com>
Date:   Tue Jan 30 11:38:25 2024 -0800

    SUNRPC: increase size of rpc_wait_queue.qlen from unsigned short to unsigned int
    
    [ Upstream commit 2c35f43b5a4b9cdfaa6fdd946f5a212615dac8eb ]
    
    When the NFS client is under extreme load the rpc_wait_queue.qlen counter
    can be overflowed. Here is an instant of the backlog queue overflow in a
    real world environment shown by drgn helper:
    
    rpc_task_stats(rpc_clnt):
    -------------------------
    rpc_clnt: 0xffff92b65d2bae00
    rpc_xprt: 0xffff9275db64f000
      Queue:  sending[64887] pending[524] backlog[30441] binding[0]
    XMIT task: 0xffff925c6b1d8e98
         WRITE: 750654
            __dta_call_status_580: 65463
            __dta_call_transmit_status_579: 1
            call_reserveresult: 685189
            nfs_client_init_is_complete: 1
        COMMIT: 584
            call_reserveresult: 573
            __dta_call_status_580: 11
        ACCESS: 1
            __dta_call_status_580: 1
       GETATTR: 10
            __dta_call_status_580: 4
            call_reserveresult: 6
    751249 tasks for server 111.222.333.444
    Total tasks: 751249
    
    count_rpc_wait_queues(xprt):
    ----------------------------
    **** rpc_xprt: 0xffff9275db64f000 num_reqs: 65511
    wait_queue: xprt_binding[0] cnt: 0
    wait_queue: xprt_binding[1] cnt: 0
    wait_queue: xprt_binding[2] cnt: 0
    wait_queue: xprt_binding[3] cnt: 0
    rpc_wait_queue[xprt_binding].qlen: 0 maxpriority: 0
    wait_queue: xprt_sending[0] cnt: 0
    wait_queue: xprt_sending[1] cnt: 64887
    wait_queue: xprt_sending[2] cnt: 0
    wait_queue: xprt_sending[3] cnt: 0
    rpc_wait_queue[xprt_sending].qlen: 64887 maxpriority: 3
    wait_queue: xprt_pending[0] cnt: 524
    wait_queue: xprt_pending[1] cnt: 0
    wait_queue: xprt_pending[2] cnt: 0
    wait_queue: xprt_pending[3] cnt: 0
    rpc_wait_queue[xprt_pending].qlen: 524 maxpriority: 0
    wait_queue: xprt_backlog[0] cnt: 0
    wait_queue: xprt_backlog[1] cnt: 685801
    wait_queue: xprt_backlog[2] cnt: 0
    wait_queue: xprt_backlog[3] cnt: 0
    rpc_wait_queue[xprt_backlog].qlen: 30441 maxpriority: 3 [task cnt mismatch]
    
    There is no effect on operations when this overflow occurs. However
    it causes confusion when trying to diagnose the performance problem.
    
    Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
sysv: don't call sb_bread() with pointers_lock held [+ + +]
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Mon Apr 10 21:04:50 2023 +0900

    sysv: don't call sb_bread() with pointers_lock held
    
    [ Upstream commit f123dc86388cb669c3d6322702dc441abc35c31e ]
    
    syzbot is reporting sleep in atomic context in SysV filesystem [1], for
    sb_bread() is called with rw_spinlock held.
    
    A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug
    and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by
    "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12.
    
    Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the
    former bug by moving pointers_lock lock to the callers, but instead
    introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made
    this problem easier to hit).
    
    Al Viro suggested that why not to do like get_branch()/get_block()/
    find_shared() in Minix filesystem does. And doing like that is almost a
    revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch()
     from with find_shared() is called without write_lock(&pointers_lock).
    
    Reported-by: syzbot <syzbot+69b40dc5fd40f32c199f@syzkaller.appspotmail.com>
    Link: https://syzkaller.appspot.com/bug?extid=69b40dc5fd40f32c199f
    Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Link: https://lore.kernel.org/r/0d195f93-a22a-49a2-0020-103534d6f7f6@I-love.SAKURA.ne.jp
    Signed-off-by: Christian Brauner <brauner@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp: properly terminate timers for kernel sockets [+ + +]
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Mar 22 13:57:32 2024 +0000

    tcp: properly terminate timers for kernel sockets
    
    [ Upstream commit 151c9c724d05d5b0dd8acd3e11cb69ef1f2dbada ]
    
    We had various syzbot reports about tcp timers firing after
    the corresponding netns has been dismantled.
    
    Fortunately Josef Bacik could trigger the issue more often,
    and could test a patch I wrote two years ago.
    
    When TCP sockets are closed, we call inet_csk_clear_xmit_timers()
    to 'stop' the timers.
    
    inet_csk_clear_xmit_timers() can be called from any context,
    including when socket lock is held.
    This is the reason it uses sk_stop_timer(), aka del_timer().
    This means that ongoing timers might finish much later.
    
    For user sockets, this is fine because each running timer
    holds a reference on the socket, and the user socket holds
    a reference on the netns.
    
    For kernel sockets, we risk that the netns is freed before
    timer can complete, because kernel sockets do not hold
    reference on the netns.
    
    This patch adds inet_csk_clear_xmit_timers_sync() function
    that using sk_stop_timer_sync() to make sure all timers
    are terminated before the kernel socket is released.
    Modules using kernel sockets close them in their netns exit()
    handler.
    
    Also add sock_not_owned_by_me() helper to get LOCKDEP
    support : inet_csk_clear_xmit_timers_sync() must not be called
    while socket lock is held.
    
    It is very possible we can revert in the future commit
    3a58f13a881e ("net: rds: acquire refcount on TCP sockets")
    which attempted to solve the issue in rds only.
    (net/smc/af_smc.c and net/mptcp/subflow.c have similar code)
    
    We probably can remove the check_net() tests from
    tcp_out_of_resources() and __tcp_close() in the future.
    
    Reported-by: Josef Bacik <josef@toxicpanda.com>
    Closes: https://lore.kernel.org/netdev/20240314210740.GA2823176@perftesting/
    Fixes: 26abe14379f8 ("net: Modify sk_alloc to not reference count the netns of kernel sockets.")
    Fixes: 8a68173691f0 ("net: sk_clone_lock() should only do get_net() if the parent is not a kernel socket")
    Link: https://lore.kernel.org/bpf/CANn89i+484ffqb93aQm1N-tjxxvb3WDKX0EbD7318RwRgsatjw@mail.gmail.com/
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Tested-by: Josef Bacik <josef@toxicpanda.com>
    Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Link: https://lore.kernel.org/r/20240322135732.1535772-1-edumazet@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tee: optee: Fix kernel panic caused by incorrect error handling [+ + +]
Author: Sumit Garg <sumit.garg@linaro.org>
Date:   Fri Mar 1 20:07:31 2024 +0530

    tee: optee: Fix kernel panic caused by incorrect error handling
    
    commit 95915ba4b987cf2b222b0f251280228a1ff977ac upstream.
    
    The error path while failing to register devices on the TEE bus has a
    bug leading to kernel panic as follows:
    
    [   15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c
    [   15.406913] Mem abort info:
    [   15.409722]   ESR = 0x0000000096000005
    [   15.413490]   EC = 0x25: DABT (current EL), IL = 32 bits
    [   15.418814]   SET = 0, FnV = 0
    [   15.421878]   EA = 0, S1PTW = 0
    [   15.425031]   FSC = 0x05: level 1 translation fault
    [   15.429922] Data abort info:
    [   15.432813]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
    [   15.438310]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    [   15.443372]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    [   15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000
    [   15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000
    [   15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
    
    Commit 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration")
    lead to the introduction of this bug. So fix it appropriately.
    
    Reported-by: Mikko Rapeli <mikko.rapeli@linaro.org>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218542
    Fixes: 7269cba53d90 ("tee: optee: Fix supplicant based device enumeration")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
    Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
timers: Rename del_timer_sync() to timer_delete_sync() [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Nov 23 21:18:44 2022 +0100

    timers: Rename del_timer_sync() to timer_delete_sync()
    
    [ Upstream commit 9b13df3fb64ee95e2397585404e442afee2c7d4f ]
    
    The timer related functions do not have a strict timer_ prefixed namespace
    which is really annoying.
    
    Rename del_timer_sync() to timer_delete_sync() and provide del_timer_sync()
    as a wrapper. Document that del_timer_sync() is not for new code.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
    Link: https://lore.kernel.org/r/20221123201624.954785441@linutronix.de
    Stable-dep-of: 0f7352557a35 ("wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

timers: Update kernel-doc for various functions [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Nov 23 21:18:40 2022 +0100

    timers: Update kernel-doc for various functions
    
    [ Upstream commit 14f043f1340bf30bc60af127bff39f55889fef26 ]
    
    The kernel-doc of timer related functions is partially uncomprehensible
    word salad. Rewrite it to make it useful.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
    Link: https://lore.kernel.org/r/20221123201624.828703870@linutronix.de
    Stable-dep-of: 0f7352557a35 ("wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

timers: Use del_timer_sync() even on UP [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Wed Nov 23 21:18:42 2022 +0100

    timers: Use del_timer_sync() even on UP
    
    [ Upstream commit 168f6b6ffbeec0b9333f3582e4cf637300858db5 ]
    
    del_timer_sync() is assumed to be pointless on uniprocessor systems and can
    be mapped to del_timer() because in theory del_timer() can never be invoked
    while the timer callback function is executed.
    
    This is not entirely true because del_timer() can be invoked from interrupt
    context and therefore hit in the middle of a running timer callback.
    
    Contrary to that del_timer_sync() is not allowed to be invoked from
    interrupt context unless the affected timer is marked with TIMER_IRQSAFE.
    del_timer_sync() has proper checks in place to detect such a situation.
    
    Give up on the UP optimization and make del_timer_sync() unconditionally
    available.
    
    Co-developed-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
    Reviewed-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
    Link: https://lore.kernel.org/all/20220407161745.7d6754b3@gandalf.local.home
    Link: https://lore.kernel.org/all/20221110064101.429013735@goodmis.org
    Link: https://lore.kernel.org/r/20221123201624.888306160@linutronix.de
    Stable-dep-of: 0f7352557a35 ("wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools/power x86_energy_perf_policy: Fix file leak in get_pkg_num() [+ + +]
Author: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
Date:   Tue Feb 13 16:19:56 2024 -0800

    tools/power x86_energy_perf_policy: Fix file leak in get_pkg_num()
    
    [ Upstream commit f85450f134f0b4ca7e042dc3dc89155656a2299d ]
    
    In function get_pkg_num() if fopen_or_die() succeeds it returns a file
    pointer to be used. But fclose() is never called before returning from
    the function.
    
    Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tools: iio: replace seekdir() in iio_generic_buffer [+ + +]
Author: Petre Rodan <petre.rodan@subdimension.ro>
Date:   Mon Jan 8 12:32:20 2024 +0200

    tools: iio: replace seekdir() in iio_generic_buffer
    
    [ Upstream commit 4e6500bfa053dc133021f9c144261b77b0ba7dc8 ]
    
    Replace seekdir() with rewinddir() in order to fix a localized glibc bug.
    
    One of the glibc patches that stable Gentoo is using causes an improper
    directory stream positioning bug on 32bit arm. That in turn ends up as a
    floating point exception in iio_generic_buffer.
    
    The attached patch provides a fix by using an equivalent function which
    should not cause trouble for other distros and is easier to reason about
    in general as it obviously always goes back to to the start.
    
    https://sourceware.org/bugzilla/show_bug.cgi?id=31212
    
    Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro>
    Link: https://lore.kernel.org/r/20240108103224.3986-1-petre.rodan@subdimension.ro
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc [+ + +]
Author: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Date:   Mon Jul 31 15:59:42 2023 -0300

    tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
    
    commit 67c37756898a5a6b2941a13ae7260c89b54e0d88 upstream.
    
    Any unprivileged user can attach N_GSM0710 ldisc, but it requires
    CAP_NET_ADMIN to create a GSM network anyway.
    
    Require initial namespace CAP_NET_ADMIN to do that.
    
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
    Link: https://lore.kernel.org/r/20230731185942.279611-1-cascardo@canonical.com
    Cc: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: serial: fsl_lpuart: avoid idle preamble pending if CTS is enabled [+ + +]
Author: Sherry Sun <sherry.sun@nxp.com>
Date:   Tue Mar 5 09:57:06 2024 +0800

    tty: serial: fsl_lpuart: avoid idle preamble pending if CTS is enabled
    
    commit 74cb7e0355fae9641f825afa389d3fba3b617714 upstream.
    
    If the remote uart device is not connected or not enabled after booting
    up, the CTS line is high by default. At this time, if we enable the flow
    control when opening the device(for example, using “stty -F /dev/ttyLP4
    crtscts” command), there will be a pending idle preamble(first writing 0
    and then writing 1 to UARTCTRL_TE will queue an idle preamble) that
    cannot be sent out, resulting in the uart port fail to close(waiting for
    TX empty), so the user space stty will have to wait for a long time or
    forever.
    
    This is an LPUART IP bug(idle preamble has higher priority than CTS),
    here add a workaround patch to enable TX CTS after enabling UARTCTRL_TE,
    so that the idle preamble does not get stuck due to CTS is deasserted.
    
    Fixes: 380c966c093e ("tty: serial: fsl_lpuart: add 32-bit register interface support")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
    Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
    Link: https://lore.kernel.org/r/20240305015706.1050769-1-sherry.sun@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ubi: Check for too small LEB size in VTBL code [+ + +]
Author: Richard Weinberger <richard@nod.at>
Date:   Wed Jan 24 07:37:02 2024 +0100

    ubi: Check for too small LEB size in VTBL code
    
    [ Upstream commit 68a24aba7c593eafa8fd00f2f76407b9b32b47a9 ]
    
    If the LEB size is smaller than a volume table record we cannot
    have volumes.
    In this case abort attaching.
    
    Cc: Chenyuan Yang <cy54@illinois.edu>
    Cc: stable@vger.kernel.org
    Fixes: 801c135ce73d ("UBI: Unsorted Block Images")
    Reported-by: Chenyuan Yang <cy54@illinois.edu>
    Closes: https://lore.kernel.org/linux-mtd/1433EB7A-FC89-47D6-8F47-23BE41B263B3@illinois.edu/
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ubi: correct the calculation of fastmap size [+ + +]
Author: Zhang Yi <yi.zhang@huawei.com>
Date:   Tue Feb 20 10:49:03 2024 +0800

    ubi: correct the calculation of fastmap size
    
    [ Upstream commit 7f174ae4f39e8475adcc09d26c5a43394689ad6c ]
    
    Now that the calculation of fastmap size in ubi_calc_fm_size() is
    incorrect since it miss each user volume's ubi_fm_eba structure and the
    Internal UBI volume info. Let's correct the calculation.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
    Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ubifs: Set page uptodate in the correct place [+ + +]
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Wed Jan 24 17:52:44 2024 +0000

    ubifs: Set page uptodate in the correct place
    
    [ Upstream commit 723012cab779eee8228376754e22c6594229bf8f ]
    
    Page cache reads are lockless, so setting the freshly allocated page
    uptodate before we've overwritten it with the data it's supposed to have
    in it will allow a simultaneous reader to see old data.  Move the call
    to SetPageUptodate into ubifs_write_end(), which is after we copied the
    new data into the page.
    
    Fixes: 1e51764a3c2a ("UBIFS: add new flash file system")
    Cc: stable@vger.kernel.org
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
udp: do not accept non-tunnel GSO skbs landing in a tunnel [+ + +]
Author: Antoine Tenart <atenart@kernel.org>
Date:   Tue Mar 26 12:33:58 2024 +0100

    udp: do not accept non-tunnel GSO skbs landing in a tunnel
    
    [ Upstream commit 3d010c8031e39f5fa1e8b13ada77e0321091011f ]
    
    When rx-udp-gro-forwarding is enabled UDP packets might be GROed when
    being forwarded. If such packets might land in a tunnel this can cause
    various issues and udp_gro_receive makes sure this isn't the case by
    looking for a matching socket. This is performed in
    udp4/6_gro_lookup_skb but only in the current netns. This is an issue
    with tunneled packets when the endpoint is in another netns. In such
    cases the packets will be GROed at the UDP level, which leads to various
    issues later on. The same thing can happen with rx-gro-list.
    
    We saw this with geneve packets being GROed at the UDP level. In such
    case gso_size is set; later the packet goes through the geneve rx path,
    the geneve header is pulled, the offset are adjusted and frag_list skbs
    are not adjusted with regard to geneve. When those skbs hit
    skb_fragment, it will misbehave. Different outcomes are possible
    depending on what the GROed skbs look like; from corrupted packets to
    kernel crashes.
    
    One example is a BUG_ON[1] triggered in skb_segment while processing the
    frag_list. Because gso_size is wrong (geneve header was pulled)
    skb_segment thinks there is "geneve header size" of data in frag_list,
    although it's in fact the next packet. The BUG_ON itself has nothing to
    do with the issue. This is only one of the potential issues.
    
    Looking up for a matching socket in udp_gro_receive is fragile: the
    lookup could be extended to all netns (not speaking about performances)
    but nothing prevents those packets from being modified in between and we
    could still not find a matching socket. It's OK to keep the current
    logic there as it should cover most cases but we also need to make sure
    we handle tunnel packets being GROed too early.
    
    This is done by extending the checks in udp_unexpected_gso: GSO packets
    lacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel must
    be segmented.
    
    [1] kernel BUG at net/core/skbuff.c:4408!
        RIP: 0010:skb_segment+0xd2a/0xf70
        __udp_gso_segment+0xaa/0x560
    
    Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
    Fixes: 36707061d6ba ("udp: allow forwarding of plain (non-fraglisted) UDP GRO packets")
    Signed-off-by: Antoine Tenart <atenart@kernel.org>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

udp: do not transition UDP GRO fraglist partial checksums to unnecessary [+ + +]
Author: Antoine Tenart <atenart@kernel.org>
Date:   Tue Mar 26 12:34:00 2024 +0100

    udp: do not transition UDP GRO fraglist partial checksums to unnecessary
    
    commit f0b8c30345565344df2e33a8417a27503589247d upstream.
    
    UDP GRO validates checksums and in udp4/6_gro_complete fraglist packets
    are converted to CHECKSUM_UNNECESSARY to avoid later checks. However
    this is an issue for CHECKSUM_PARTIAL packets as they can be looped in
    an egress path and then their partial checksums are not fixed.
    
    Different issues can be observed, from invalid checksum on packets to
    traces like:
    
      gen01: hw csum failure
      skb len=3008 headroom=160 headlen=1376 tailroom=0
      mac=(106,14) net=(120,40) trans=160
      shinfo(txflags=0 nr_frags=0 gso(size=0 type=0 segs=0))
      csum(0xffff232e ip_summed=2 complete_sw=0 valid=0 level=0)
      hash(0x77e3d716 sw=1 l4=1) proto=0x86dd pkttype=0 iif=12
      ...
    
    Fix this by only converting CHECKSUM_NONE packets to
    CHECKSUM_UNNECESSARY by reusing __skb_incr_checksum_unnecessary. All
    other checksum types are kept as-is, including CHECKSUM_COMPLETE as
    fraglist packets being segmented back would have their skb->csum valid.
    
    Fixes: 9fd1ff5d2ac7 ("udp: Support UDP fraglist GRO/GSO.")
    Signed-off-by: Antoine Tenart <atenart@kernel.org>
    Reviewed-by: Willem de Bruijn <willemb@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: cdc-wdm: close race between read and workqueue [+ + +]
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Mar 14 12:50:48 2024 +0100

    usb: cdc-wdm: close race between read and workqueue
    
    commit 339f83612f3a569b194680768b22bf113c26a29d upstream.
    
    wdm_read() cannot race with itself. However, in
    service_outstanding_interrupt() it can race with the
    workqueue, which can be triggered by error handling.
    
    Hence we need to make sure that the WDM_RESPONDING
    flag is not just only set but tested.
    
    Fixes: afba937e540c9 ("USB: CDC WDM driver")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20240314115132.3907-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: core: Add hub_get() and hub_put() routines [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Fri Mar 15 13:04:50 2024 -0400

    USB: core: Add hub_get() and hub_put() routines
    
    commit ee113b860aa169e9a4d2c167c95d0f1961c6e1b8 upstream.
    
    Create hub_get() and hub_put() routines to encapsulate the kref_get()
    and kref_put() calls in hub.c.  The new routines will be used by the
    next patch in this series.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/604da420-ae8a-4a9e-91a4-2d511ff404fb@rowland.harvard.edu
    Cc: stable <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: core: Fix deadlock in usb_deauthorize_interface() [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Mar 12 11:48:23 2024 -0400

    USB: core: Fix deadlock in usb_deauthorize_interface()
    
    commit 80ba43e9f799cbdd83842fc27db667289b3150f5 upstream.
    
    Among the attribute file callback routines in
    drivers/usb/core/sysfs.c, the interface_authorized_store() function is
    the only one which acquires a device lock on an ancestor device: It
    calls usb_deauthorize_interface(), which locks the interface's parent
    USB device.
    
    The will lead to deadlock if another process already owns that lock
    and tries to remove the interface, whether through a configuration
    change or because the device has been disconnected.  As part of the
    removal procedure, device_del() waits for all ongoing sysfs attribute
    callbacks to complete.  But usb_deauthorize_interface() can't complete
    until the device lock has been released, and the lock won't be
    released until the removal has finished.
    
    The mechanism provided by sysfs to prevent this kind of deadlock is
    to use the sysfs_break_active_protection() function, which tells sysfs
    not to wait for the attribute callback.
    
    Reported-and-tested by: Yue Sun <samsun1006219@gmail.com>
    Reported by: xingwei lee <xrivendell7@gmail.com>
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/linux-usb/CAEkJfYO6jRVC8Tfrd_R=cjO0hguhrV31fDPrLrNOOHocDkPoAA@mail.gmail.com/#r
    Fixes: 310d2b4124c0 ("usb: interface authorization: SysFS part of USB interface authorization")
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/1c37eea1-9f56-4534-b9d8-b443438dc869@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: dwc2: gadget: LPM flow fix [+ + +]
Author: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Date:   Wed Mar 13 09:22:13 2024 +0000

    usb: dwc2: gadget: LPM flow fix
    
    commit 5d69a3b54e5a630c90d82a4c2bdce3d53dc78710 upstream.
    
    Added functionality to exit from L1 state by device initiation
    using remote wakeup signaling, in case when function driver queuing
    request while core in L1 state.
    
    Fixes: 273d576c4d41 ("usb: dwc2: gadget: Add functionality to exit from LPM L1 state")
    Fixes: 88b02f2cb1e1 ("usb: dwc2: Add core state checking")
    CC: stable@vger.kernel.org
    Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
    Link: https://lore.kernel.org/r/b4d9de5382375dddbf7ef6049d9a82066ad87d5d.1710166393.git.Minas.Harutyunyan@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc2: host: Fix hibernation flow [+ + +]
Author: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Date:   Wed Mar 13 09:21:11 2024 +0000

    usb: dwc2: host: Fix hibernation flow
    
    commit 3c7b9856a82227db01a20171d2e24c7ce305d59b upstream.
    
    Added to backup/restore registers HFLBADDR, HCCHARi, HCSPLTi,
    HCTSIZi, HCDMAi and HCDMABi.
    
    Fixes: 58e52ff6a6c3 ("usb: dwc2: Move register save and restore functions")
    Fixes: d17ee77b3044 ("usb: dwc2: add controller hibernation support")
    CC: stable@vger.kernel.org
    Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
    Link: https://lore.kernel.org/r/c2d10ee6098b9b009a8e94191e046004747d3bdd.1708945444.git.Minas.Harutyunyan@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc2: host: Fix ISOC flow in DDMA mode [+ + +]
Author: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Date:   Wed Mar 13 09:21:32 2024 +0000

    usb: dwc2: host: Fix ISOC flow in DDMA mode
    
    commit b258e42688501cadb1a6dd658d6f015df9f32d8f upstream.
    
    Fixed ISOC completion flow in DDMA mode. Added isoc
    descriptor actual length value and update urb's start_frame
    value.
    Fixed initialization of ISOC DMA descriptors flow.
    
    Fixes: 56f5b1cff22a ("staging: Core files for the DWC2 driver")
    Fixes: 20f2eb9c4cf8 ("staging: dwc2: add microframe scheduler from downstream Pi kernel")
    Fixes: c17b337c1ea4 ("usb: dwc2: host: program descriptor for next frame")
    Fixes: dc4c76e7b22c ("staging: HCD descriptor DMA support for the DWC2 driver")
    Fixes: 762d3a1a9cd7 ("usb: dwc2: host: process all completed urbs")
    CC: stable@vger.kernel.org
    Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
    Link: https://lore.kernel.org/r/a8b1e1711cc6cabfb45d92ede12e35445c66f06c.1708944698.git.Minas.Harutyunyan@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: dwc2: host: Fix remote wakeup from hibernation [+ + +]
Author: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Date:   Wed Mar 13 09:21:21 2024 +0000

    usb: dwc2: host: Fix remote wakeup from hibernation
    
    commit bae2bc73a59c200db53b6c15fb26bb758e2c6108 upstream.
    
    Starting from core v4.30a changed order of programming
    GPWRDN_PMUACTV to 0 in case of exit from hibernation on
    remote wakeup signaling from device.
    
    Fixes: c5c403dc4336 ("usb: dwc2: Add host/device hibernation functions")
    CC: stable@vger.kernel.org
    Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
    Link: https://lore.kernel.org/r/99385ec55ce73445b6fbd0f471c9bd40eb1c9b9e.1708939799.git.Minas.Harutyunyan@synopsys.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: ncm: Fix handling of zero block length packets [+ + +]
Author: Krishna Kurapati <quic_kriskura@quicinc.com>
Date:   Wed Feb 28 17:24:41 2024 +0530

    usb: gadget: ncm: Fix handling of zero block length packets
    
    commit f90ce1e04cbcc76639d6cba0fdbd820cd80b3c70 upstream.
    
    While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX
    set to 65536, it has been observed that we receive short packets,
    which come at interval of 5-10 seconds sometimes and have block
    length zero but still contain 1-2 valid datagrams present.
    
    According to the NCM spec:
    
    "If wBlockLength = 0x0000, the block is terminated by a
    short packet. In this case, the USB transfer must still
    be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If
    exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,
    and the size is a multiple of wMaxPacketSize for the
    given pipe, then no ZLP shall be sent.
    
    wBlockLength= 0x0000 must be used with extreme care, because
    of the possibility that the host and device may get out of
    sync, and because of test issues.
    
    wBlockLength = 0x0000 allows the sender to reduce latency by
    starting to send a very large NTB, and then shortening it when
    the sender discovers that there’s not sufficient data to justify
    sending a large NTB"
    
    However, there is a potential issue with the current implementation,
    as it checks for the occurrence of multiple NTBs in a single
    giveback by verifying if the leftover bytes to be processed is zero
    or not. If the block length reads zero, we would process the same
    NTB infintely because the leftover bytes is never zero and it leads
    to a crash. Fix this by bailing out if block length reads zero.
    
    Cc: stable@vger.kernel.org
    Fixes: 427694cfaafa ("usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call")
    Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
    Reviewed-by: Maciej Żenczykowski <maze@google.com>
    Link: https://lore.kernel.org/r/20240228115441.2105585-1-quic_kriskura@quicinc.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: gadget: tegra-xudc: Fix USB3 PHY retrieval logic [+ + +]
Author: Wayne Chang <waynec@nvidia.com>
Date:   Thu Mar 7 11:03:28 2024 +0800

    usb: gadget: tegra-xudc: Fix USB3 PHY retrieval logic
    
    [ Upstream commit 84fa943d93c31ee978355e6c6c69592dae3c9f59 ]
    
    This commit resolves an issue in the tegra-xudc USB gadget driver that
    incorrectly fetched USB3 PHY instances. The problem stemmed from the
    assumption of a one-to-one correspondence between USB2 and USB3 PHY
    names and their association with physical USB ports in the device tree.
    
    Previously, the driver associated USB3 PHY names directly with the USB3
    instance number, leading to mismatches when mapping the physical USB
    ports. For instance, if using USB3-1 PHY, the driver expect the
    corresponding PHY name as 'usb3-1'. However, the physical USB ports in
    the device tree were designated as USB2-0 and USB3-0 as we only have
    one device controller, causing a misalignment.
    
    This commit rectifies the issue by adjusting the PHY naming logic.
    Now, the driver correctly correlates the USB2 and USB3 PHY instances,
    allowing the USB2-0 and USB3-1 PHYs to form a physical USB port pair
    while accurately reflecting their configuration in the device tree by
    naming them USB2-0 and USB3-0, respectively.
    
    The change ensures that the PHY and PHY names align appropriately,
    resolving the mismatch between physical USB ports and their associated
    names in the device tree.
    
    Fixes: b4e19931c98a ("usb: gadget: tegra-xudc: Support multiple device modes")
    Cc: stable@vger.kernel.org
    Signed-off-by: Wayne Chang <waynec@nvidia.com>
    Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Link: https://lore.kernel.org/r/20240307030328.1487748-3-waynec@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: gadget: tegra-xudc: Use dev_err_probe() [+ + +]
Author: Jon Hunter <jonathanh@nvidia.com>
Date:   Wed May 19 17:35:53 2021 +0100

    usb: gadget: tegra-xudc: Use dev_err_probe()
    
    [ Upstream commit 77b57218ac2f37da4e8b72e78f002944b9f85091 ]
    
    Rather than testing if the error code is -EPROBE_DEFER before printing
    an error message, use dev_err_probe() instead to simplify the code.
    
    Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
    Link: https://lore.kernel.org/r/20210519163553.212682-2-jonathanh@nvidia.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 84fa943d93c3 ("usb: gadget: tegra-xudc: Fix USB3 PHY retrieval logic")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: port: Don't try to peer unused USB ports based on location [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Feb 23 01:33:43 2024 +0200

    usb: port: Don't try to peer unused USB ports based on location
    
    commit 69c63350e573367f9c8594162288cffa8a26d0d1 upstream.
    
    Unused USB ports may have bogus location data in ACPI PLD tables.
    This causes port peering failures as these unused USB2 and USB3 ports
    location may match.
    
    Due to these failures the driver prints a
    "usb: port power management may be unreliable" warning, and
    unnecessarily blocks port power off during runtime suspend.
    
    This was debugged on a couple DELL systems where the unused ports
    all returned zeroes in their location data.
    Similar bugreports exist for other systems.
    
    Don't try to peer or match ports that have connect type set to
    USB_PORT_NOT_USED.
    
    Fixes: 3bfd659baec8 ("usb: find internal hub tier mismatch via acpi")
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218465
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218486
    Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Link: https://lore.kernel.org/linux-usb/5406d361-f5b7-4309-b0e6-8c94408f7d75@molgen.mpg.de
    Cc: stable@vger.kernel.org # v3.16+
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218490
    Link: https://lore.kernel.org/r/20240222233343.71856-1-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: serial: add device ID for VeriFone adapter [+ + +]
Author: Cameron Williams <cang1@live.co.uk>
Date:   Tue Feb 13 21:53:29 2024 +0000

    USB: serial: add device ID for VeriFone adapter
    
    [ Upstream commit cda704809797a8a86284f9df3eef5e62ec8a3175 ]
    
    Add device ID for a (probably fake) CP2102 UART device.
    
    lsusb -v output:
    
    Device Descriptor:
      bLength                18
      bDescriptorType         1
      bcdUSB               1.10
      bDeviceClass            0 [unknown]
      bDeviceSubClass         0 [unknown]
      bDeviceProtocol         0
      bMaxPacketSize0        64
      idVendor           0x11ca VeriFone Inc
      idProduct          0x0212 Verifone USB to Printer
      bcdDevice            1.00
      iManufacturer           1 Silicon Labs
      iProduct                2 Verifone USB to Printer
      iSerial                 3 0001
      bNumConfigurations      1
      Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength       0x0020
        bNumInterfaces          1
        bConfigurationValue     1
        iConfiguration          0
        bmAttributes         0x80
          (Bus Powered)
        MaxPower              100mA
        Interface Descriptor:
          bLength                 9
          bDescriptorType         4
          bInterfaceNumber        0
          bAlternateSetting       0
          bNumEndpoints           2
          bInterfaceClass       255 Vendor Specific Class
          bInterfaceSubClass      0 [unknown]
          bInterfaceProtocol      0
          iInterface              2 Verifone USB to Printer
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x81  EP 1 IN
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               0
          Endpoint Descriptor:
            bLength                 7
            bDescriptorType         5
            bEndpointAddress     0x01  EP 1 OUT
            bmAttributes            2
              Transfer Type            Bulk
              Synch Type               None
              Usage Type               Data
            wMaxPacketSize     0x0040  1x 64 bytes
            bInterval               0
    Device Status:     0x0000
      (Bus Powered)
    
    Signed-off-by: Cameron Williams <cang1@live.co.uk>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

USB: serial: cp210x: add ID for MGP Instruments PDS100 [+ + +]
Author: Christian Häggström <christian.haggstrom@orexplore.com>
Date:   Wed Feb 14 11:47:29 2024 +0100

    USB: serial: cp210x: add ID for MGP Instruments PDS100
    
    [ Upstream commit a0d9d868491a362d421521499d98308c8e3a0398 ]
    
    The radiation meter has the text MGP Instruments PDS-100G or PDS-100GN
    produced by Mirion Technologies. Tested by forcing the driver
    association with
    
      echo 10c4 863c > /sys/bus/usb-serial/drivers/cp210x/new_id
    
    and then setting the serial port in 115200 8N1 mode. The device
    announces ID_USB_VENDOR_ENC=Silicon\x20Labs and ID_USB_MODEL_ENC=PDS100
    
    Signed-off-by: Christian Häggström <christian.haggstrom@orexplore.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

USB: serial: cp210x: add pid/vid for TDK NC0110013M and MM0110113M [+ + +]
Author: Toru Katagiri <Toru.Katagiri@tdk.com>
Date:   Tue Mar 5 08:46:14 2024 +0900

    USB: serial: cp210x: add pid/vid for TDK NC0110013M and MM0110113M
    
    [ Upstream commit b1a8da9ff1395c4879b4bd41e55733d944f3d613 ]
    
    TDK NC0110013M and MM0110113M have custom USB IDs for CP210x,
    so we need to add them to the driver.
    
    Signed-off-by: Toru Katagiri <Toru.Katagiri@tdk.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

USB: serial: ftdi_sio: add support for GMC Z216C Adapter IR-USB [+ + +]
Author: Daniel Vogelbacher <daniel@chaospixel.com>
Date:   Sun Feb 11 15:42:46 2024 +0100

    USB: serial: ftdi_sio: add support for GMC Z216C Adapter IR-USB
    
    [ Upstream commit 3fb7bc4f3a98c48981318b87cf553c5f115fd5ca ]
    
    The GMC IR-USB adapter cable utilizes a FTDI FT232R chip.
    
    Add VID/PID for this adapter so it can be used as serial device via
    ftdi_sio.
    
    Signed-off-by: Daniel Vogelbacher <daniel@chaospixel.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

USB: serial: option: add MeiG Smart SLM320 product [+ + +]
Author: Aurélien Jacobs <aurel@gnuage.org>
Date:   Wed Jan 31 18:49:17 2024 +0100

    USB: serial: option: add MeiG Smart SLM320 product
    
    [ Upstream commit 46809c51565b83881aede6cdf3b0d25254966a41 ]
    
    Update the USB serial option driver to support MeiG Smart SLM320.
    
    ID 2dee:4d41 UNISOC UNISOC-8910
    
    T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 9 Spd=480 MxCh= 0
    D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
    P: Vendor=2dee ProdID=4d41 Rev=00.00
    S: Manufacturer=UNISOC
    S: Product=UNISOC-8910
    C: #Ifs= 8 Cfg#= 1 Atr=e0 MxPwr=400mA
    I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I: If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I: If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I: If#= 7 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
    E: Ad=08(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Tested successfully a PPP LTE connection using If#= 0.
    Not sure of the purpose of every other serial interfaces.
    
    Signed-off-by: Aurélien Jacobs <aurel@gnuage.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
usb: sl811-hcd: only defined function checkdone if QUIRK2 is defined [+ + +]
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Thu Mar 7 11:13:51 2024 +0000

    usb: sl811-hcd: only defined function checkdone if QUIRK2 is defined
    
    [ Upstream commit 12f371e2b6cb4b79c788f1f073992e115f4ca918 ]
    
    Function checkdone is only required if QUIRK2 is defined, so add
    appropriate #if / #endif around the function.
    
    Cleans up clang scan build warning:
    drivers/usb/host/sl811-hcd.c:588:18: warning: unused function
    'checkdone' [-Wunused-function]
    
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Link: https://lore.kernel.org/r/20240307111351.1982382-1-colin.i.king@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: typec: tcpci: add generic tcpci fallback compatible [+ + +]
Author: Marco Felsch <m.felsch@pengutronix.de>
Date:   Thu Feb 22 22:09:01 2024 +0100

    usb: typec: tcpci: add generic tcpci fallback compatible
    
    [ Upstream commit 8774ea7a553e2aec323170d49365b59af0a2b7e0 ]
    
    The driver already support the tcpci binding for the i2c_device_id so
    add the support for the of_device_id too.
    
    Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://lore.kernel.org/r/20240222210903.208901-3-m.felsch@pengutronix.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: typec: ucsi: Ack unsupported commands [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Wed Mar 20 08:39:24 2024 +0100

    usb: typec: ucsi: Ack unsupported commands
    
    commit 6b5c85ddeea77d18c4b69e3bda60e9374a20c304 upstream.
    
    If a command completes the OPM must send an ack. This applies
    to unsupported commands, too.
    
    Send the required ACK for unsupported commands.
    
    Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
    Cc: stable <stable@kernel.org>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
    Link: https://lore.kernel.org/r/20240320073927.1641788-4-lk@c--e.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: typec: ucsi: Clean up UCSI_CABLE_PROP macros [+ + +]
Author: Jameson Thies <jthies@google.com>
Date:   Tue Mar 5 02:58:01 2024 +0000

    usb: typec: ucsi: Clean up UCSI_CABLE_PROP macros
    
    [ Upstream commit 4d0a5a9915793377c0fe1a8d78de6bcd92cea963 ]
    
    Clean up UCSI_CABLE_PROP macros by fixing a bitmask shifting error for
    plug type and updating the modal support macro for consistent naming.
    
    Fixes: 3cf657f07918 ("usb: typec: ucsi: Remove all bit-fields")
    Cc: stable@vger.kernel.org
    Reviewed-by: Benson Leung <bleung@chromium.org>
    Reviewed-by: Prashant Malani <pmalani@chromium.org>
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Signed-off-by: Jameson Thies <jthies@google.com>
    Link: https://lore.kernel.org/r/20240305025804.1290919-2-jthies@google.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

usb: typec: ucsi: Clear UCSI_CCI_RESET_COMPLETE before reset [+ + +]
Author: Christian A. Ehrhardt <lk@c--e.de>
Date:   Wed Mar 20 08:39:26 2024 +0100

    usb: typec: ucsi: Clear UCSI_CCI_RESET_COMPLETE before reset
    
    commit 3de4f996a0b5412aa451729008130a488f71563e upstream.
    
    Check the UCSI_CCI_RESET_COMPLETE complete flag before starting
    another reset. Use a UCSI_SET_NOTIFICATION_ENABLE command to clear
    the flag if it is set.
    
    Signed-off-by: Christian A. Ehrhardt <lk@c--e.de>
    Cc: stable <stable@kernel.org>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD
    Link: https://lore.kernel.org/r/20240320073927.1641788-6-lk@c--e.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: udc: remove warning when queue disabled ep [+ + +]
Author: yuan linyu <yuanlinyu@hihonor.com>
Date:   Fri Mar 15 10:01:44 2024 +0800

    usb: udc: remove warning when queue disabled ep
    
    commit 2a587a035214fa1b5ef598aea0b81848c5b72e5e upstream.
    
    It is possible trigger below warning message from mass storage function,
    
    WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104
    pc : usb_ep_queue+0x7c/0x104
    lr : fsg_main_thread+0x494/0x1b3c
    
    Root cause is mass storage function try to queue request from main thread,
    but other thread may already disable ep when function disable.
    
    As there is no function failure in the driver, in order to avoid effort
    to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().
    
    Suggested-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable@vger.kernel.org
    Signed-off-by: yuan linyu <yuanlinyu@hihonor.com>
    Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20240315020144.2715575-1-yuanlinyu@hihonor.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Thu Feb 29 14:30:06 2024 -0500

    USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command
    
    commit 014bcf41d946b36a8f0b8e9b5d9529efbb822f49 upstream.
    
    The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values
    in the ATA ID information to calculate cylinder and head values when
    creating a CDB for READ or WRITE commands.  The calculation involves
    division and modulus operations, which will cause a crash if either of
    these values is 0.  While this never happens with a genuine device, it
    could happen with a flawed or subversive emulation, as reported by the
    syzbot fuzzer.
    
    Protect against this possibility by refusing to bind to the device if
    either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID
    information is 0.  This requires isd200_Initialization() to return a
    negative error code when initialization fails; currently it always
    returns 0 (even when there is an error).
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Reported-and-tested-by: syzbot+28748250ab47a8f04100@syzkaller.appspotmail.com
    Link: https://lore.kernel.org/linux-usb/0000000000003eb868061245ba7f@google.com/
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Cc: stable@vger.kernel.org
    Reviewed-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com>
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
    Link: https://lore.kernel.org/r/b1e605ea-333f-4ac0-9511-da04f411763e@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vboxsf: Avoid an spurious warning if load_nls_xxx() fails [+ + +]
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date:   Wed Nov 1 11:49:48 2023 +0100

    vboxsf: Avoid an spurious warning if load_nls_xxx() fails
    
    commit de3f64b738af57e2732b91a0774facc675b75b54 upstream.
    
    If an load_nls_xxx() function fails a few lines above, the 'sbi->bdi_id' is
    still 0.
    So, in the error handling path, we will call ida_simple_remove(..., 0)
    which is not allocated yet.
    
    In order to prevent a spurious "ida_free called for id=0 which is not
    allocated." message, tweak the error handling path and add a new label.
    
    Fixes: 0fd169576648 ("fs: Add VirtualBox guest shared folder (vboxsf) support")
    Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
    Link: https://lore.kernel.org/r/d09eaaa4e2e08206c58a1a27ca9b3e81dc168773.1698835730.git.christophe.jaillet@wanadoo.fr
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vfio/fsl-mc: Block calling interrupt handler without trigger [+ + +]
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Apr 1 10:53:00 2024 -0600

    vfio/fsl-mc: Block calling interrupt handler without trigger
    
    [ Upstream commit 7447d911af699a15f8d050dfcb7c680a86f87012 ]
    
    The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is
    initially NULL and may become NULL if the user sets the trigger
    eventfd to -1.  The interrupt handler itself is guaranteed that
    trigger is always valid between request_irq() and free_irq(), but
    the loopback testing mechanisms to invoke the handler function
    need to test the trigger.  The triggering and setting ioctl paths
    both make use of igate and are therefore mutually exclusive.
    
    The vfio-fsl-mc driver does not make use of irqfds, nor does it
    support any sort of masking operations, therefore unlike vfio-pci
    and vfio-platform, the flow can remain essentially unchanged.
    
    Cc: Diana Craciun <diana.craciun@oss.nxp.com>
    Cc:  <stable@vger.kernel.org>
    Fixes: cc0ee20bd969 ("vfio/fsl-mc: trigger an interrupt via eventfd")
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Link: https://lore.kernel.org/r/20240308230557.805580-8-alex.williamson@redhat.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vfio/pci: Create persistent INTx handler [+ + +]
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Apr 1 10:52:58 2024 -0600

    vfio/pci: Create persistent INTx handler
    
    [ Upstream commit 18c198c96a815c962adc2b9b77909eec0be7df4d ]
    
    A vulnerability exists where the eventfd for INTx signaling can be
    deconfigured, which unregisters the IRQ handler but still allows
    eventfds to be signaled with a NULL context through the SET_IRQS ioctl
    or through unmask irqfd if the device interrupt is pending.
    
    Ideally this could be solved with some additional locking; the igate
    mutex serializes the ioctl and config space accesses, and the interrupt
    handler is unregistered relative to the trigger, but the irqfd path
    runs asynchronous to those.  The igate mutex cannot be acquired from the
    atomic context of the eventfd wake function.  Disabling the irqfd
    relative to the eventfd registration is potentially incompatible with
    existing userspace.
    
    As a result, the solution implemented here moves configuration of the
    INTx interrupt handler to track the lifetime of the INTx context object
    and irq_type configuration, rather than registration of a particular
    trigger eventfd.  Synchronization is added between the ioctl path and
    eventfd_signal() wrapper such that the eventfd trigger can be
    dynamically updated relative to in-flight interrupts or irqfd callbacks.
    
    Cc:  <stable@vger.kernel.org>
    Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver")
    Reported-by: Reinette Chatre <reinette.chatre@intel.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Link: https://lore.kernel.org/r/20240308230557.805580-5-alex.williamson@redhat.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vfio/pci: Disable auto-enable of exclusive INTx IRQ [+ + +]
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Apr 1 10:52:55 2024 -0600

    vfio/pci: Disable auto-enable of exclusive INTx IRQ
    
    [ Upstream commit fe9a7082684eb059b925c535682e68c34d487d43 ]
    
    Currently for devices requiring masking at the irqchip for INTx, ie.
    devices without DisINTx support, the IRQ is enabled in request_irq()
    and subsequently disabled as necessary to align with the masked status
    flag.  This presents a window where the interrupt could fire between
    these events, resulting in the IRQ incrementing the disable depth twice.
    This would be unrecoverable for a user since the masked flag prevents
    nested enables through vfio.
    
    Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx
    is never auto-enabled, then unmask as required.
    
    Cc:  <stable@vger.kernel.org>
    Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver")
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Link: https://lore.kernel.org/r/20240308230557.805580-2-alex.williamson@redhat.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vfio/pci: Lock external INTx masking ops [+ + +]
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Apr 1 10:52:56 2024 -0600

    vfio/pci: Lock external INTx masking ops
    
    [ Upstream commit 810cd4bb53456d0503cc4e7934e063835152c1b7 ]
    
    Mask operations through config space changes to DisINTx may race INTx
    configuration changes via ioctl.  Create wrappers that add locking for
    paths outside of the core interrupt code.
    
    In particular, irq_type is updated holding igate, therefore testing
    is_intx() requires holding igate.  For example clearing DisINTx from
    config space can otherwise race changes of the interrupt configuration.
    
    This aligns interfaces which may trigger the INTx eventfd into two
    camps, one side serialized by igate and the other only enabled while
    INTx is configured.  A subsequent patch introduces synchronization for
    the latter flows.
    
    Cc:  <stable@vger.kernel.org>
    Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver")
    Reported-by: Reinette Chatre <reinette.chatre@intel.com>
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Link: https://lore.kernel.org/r/20240308230557.805580-3-alex.williamson@redhat.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vfio/platform: Create persistent IRQ handlers [+ + +]
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Apr 1 10:52:59 2024 -0600

    vfio/platform: Create persistent IRQ handlers
    
    [ Upstream commit 675daf435e9f8e5a5eab140a9864dfad6668b375 ]
    
    The vfio-platform SET_IRQS ioctl currently allows loopback triggering of
    an interrupt before a signaling eventfd has been configured by the user,
    which thereby allows a NULL pointer dereference.
    
    Rather than register the IRQ relative to a valid trigger, register all
    IRQs in a disabled state in the device open path.  This allows mask
    operations on the IRQ to nest within the overall enable state governed
    by a valid eventfd signal.  This decouples @masked, protected by the
    @locked spinlock from @trigger, protected via the @igate mutex.
    
    In doing so, it's guaranteed that changes to @trigger cannot race the
    IRQ handlers because the IRQ handler is synchronously disabled before
    modifying the trigger, and loopback triggering of the IRQ via ioctl is
    safe due to serialization with trigger changes via igate.
    
    For compatibility, request_irq() failures are maintained to be local to
    the SET_IRQS ioctl rather than a fatal error in the open device path.
    This allows, for example, a userspace driver with polling mode support
    to continue to work regardless of moving the request_irq() call site.
    This necessarily blocks all SET_IRQS access to the failed index.
    
    Cc: Eric Auger <eric.auger@redhat.com>
    Cc:  <stable@vger.kernel.org>
    Fixes: 57f972e2b341 ("vfio/platform: trigger an interrupt via eventfd")
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Link: https://lore.kernel.org/r/20240308230557.805580-7-alex.williamson@redhat.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

vfio/platform: Disable virqfds on cleanup [+ + +]
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Fri Mar 8 16:05:26 2024 -0700

    vfio/platform: Disable virqfds on cleanup
    
    [ Upstream commit fcdc0d3d40bc26c105acf8467f7d9018970944ae ]
    
    irqfds for mask and unmask that are not specifically disabled by the
    user are leaked.  Remove any irqfds during cleanup
    
    Cc: Eric Auger <eric.auger@redhat.com>
    Cc:  <stable@vger.kernel.org>
    Fixes: a7fa7c77cf15 ("vfio/platform: implement IRQ masking/unmasking via an eventfd")
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Link: https://lore.kernel.org/r/20240308230557.805580-6-alex.williamson@redhat.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
vfio: Introduce interface to flush virqfd inject workqueue [+ + +]
Author: Alex Williamson <alex.williamson@redhat.com>
Date:   Mon Apr 1 10:52:57 2024 -0600

    vfio: Introduce interface to flush virqfd inject workqueue
    
    [ Upstream commit b620ecbd17a03cacd06f014a5d3f3a11285ce053 ]
    
    In order to synchronize changes that can affect the thread callback,
    introduce an interface to force a flush of the inject workqueue.  The
    irqfd pointer is only valid under spinlock, but the workqueue cannot
    be flushed under spinlock.  Therefore the flush work for the irqfd is
    queued under spinlock.  The vfio_irqfd_cleanup_wq workqueue is re-used
    for queuing this work such that flushing the workqueue is also ordered
    relative to shutdown.
    
    Reviewed-by: Kevin Tian <kevin.tian@intel.com>
    Reviewed-by: Reinette Chatre <reinette.chatre@intel.com>
    Reviewed-by: Eric Auger <eric.auger@redhat.com>
    Link: https://lore.kernel.org/r/20240308230557.805580-4-alex.williamson@redhat.com
    Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
virtio: reenable config if freezing device failed [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Tue Feb 13 14:54:25 2024 +0100

    virtio: reenable config if freezing device failed
    
    commit 310227f42882c52356b523e2f4e11690eebcd2ab upstream.
    
    Currently, we don't reenable the config if freezing the device failed.
    
    For example, virtio-mem currently doesn't support suspend+resume, and
    trying to freeze the device will always fail. Afterwards, the device
    will no longer respond to resize requests, because it won't get notified
    about config changes.
    
    Let's fix this by re-enabling the config if freezing fails.
    
    Fixes: 22b7050a024d ("virtio: defer config changed notifications")
    Cc: <stable@kernel.org>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: Jason Wang <jasowang@redhat.com>
    Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Message-Id: <20240213135425.795001-1-david@redhat.com>
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host() [+ + +]
Author: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Date:   Fri Jan 5 08:40:00 2024 -0800

    VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()
    
    [ Upstream commit 19b070fefd0d024af3daa7329cbc0d00de5302ec ]
    
    Syzkaller hit 'WARNING in dg_dispatch_as_host' bug.
    
    memcpy: detected field-spanning write (size 56) of single field "&dg_info->msg"
    at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24)
    
    WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237
    dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237
    
    Some code commentry, based on my understanding:
    
    544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)->payload_size)
    /// This is 24 + payload_size
    
    memcpy(&dg_info->msg, dg, dg_size);
            Destination = dg_info->msg ---> this is a 24 byte
                                            structure(struct vmci_datagram)
            Source = dg --> this is a 24 byte structure (struct vmci_datagram)
            Size = dg_size = 24 + payload_size
    
    {payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32.
    
     35 struct delayed_datagram_info {
     36         struct datagram_entry *entry;
     37         struct work_struct work;
     38         bool in_dg_host_queue;
     39         /* msg and msg_payload must be together. */
     40         struct vmci_datagram msg;
     41         u8 msg_payload[];
     42 };
    
    So those extra bytes of payload are copied into msg_payload[], a run time
    warning is seen while fuzzing with Syzkaller.
    
    One possible way to fix the warning is to split the memcpy() into
    two parts -- one -- direct assignment of msg and second taking care of payload.
    
    Gustavo quoted:
    "Under FORTIFY_SOURCE we should not copy data across multiple members
    in a structure."
    
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Suggested-by: Vegard Nossum <vegard.nossum@oracle.com>
    Suggested-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
    Link: https://lore.kernel.org/r/20240105164001.2129796-2-harshit.m.mogalapalli@oracle.com
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

VMCI: Fix possible memcpy() run-time warning in vmci_datagram_invoke_guest_handler() [+ + +]
Author: Vasiliy Kovalev <kovalev@altlinux.org>
Date:   Mon Feb 19 13:53:15 2024 +0300

    VMCI: Fix possible memcpy() run-time warning in vmci_datagram_invoke_guest_handler()
    
    commit e606e4b71798cc1df20e987dde2468e9527bd376 upstream.
    
    The changes are similar to those given in the commit 19b070fefd0d
    ("VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()").
    
    Fix filling of the msg and msg_payload in dg_info struct, which prevents a
    possible "detected field-spanning write" of memcpy warning that is issued
    by the tracking mechanism __fortify_memcpy_chk.
    
    Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
    Link: https://lore.kernel.org/r/20240219105315.76955-1-kovalev@altlinux.org
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vt: fix unicode buffer corruption when deleting characters [+ + +]
Author: Nicolas Pitre <nico@fluxnic.net>
Date:   Thu Feb 29 17:15:27 2024 -0500

    vt: fix unicode buffer corruption when deleting characters
    
    commit 1581dafaf0d34bc9c428a794a22110d7046d186d upstream.
    
    This is the same issue that was fixed for the VGA text buffer in commit
    39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the
    buffer"). The cure is also the same i.e. replace memcpy() with memmove()
    due to the overlaping buffers.
    
    Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
    Fixes: 81732c3b2fed ("tty vt: Fix line garbage in virtual console on command line edition")
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/sn184on2-3p0q-0qrq-0218-895349s4753o@syhkavp.arg
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
vxge: remove unnecessary cast in kfree() [+ + +]
Author: Xu Wang <vulab@iscas.ac.cn>
Date:   Fri Oct 23 16:55:33 2020 +0800

    vxge: remove unnecessary cast in kfree()
    
    [ Upstream commit b6bf4776d9e2ed4b2552d1c252fff8de3786309a ]
    
    Remove unnecessary cast in the argument to kfree.
    
    Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
    Link: https://lore.kernel.org/r/20201023085533.4792-1-vulab@iscas.ac.cn
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: e3f269ed0acc ("x86/pm: Work around false positive kmemleak report in msr_build_context()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
wifi: ath9k: fix LNA selection in ath_ant_try_scan() [+ + +]
Author: Dmitry Antipov <dmantipov@yandex.ru>
Date:   Sun Dec 17 13:29:03 2023 +0200

    wifi: ath9k: fix LNA selection in ath_ant_try_scan()
    
    [ Upstream commit d6b27eb997ef9a2aa51633b3111bc4a04748e6d3 ]
    
    In 'ath_ant_try_scan()', (most likely) the 2nd LNA's signal
    strength should be used in comparison against RSSI when
    selecting first LNA as the main one. Compile tested only.
    
    Found by Linux Verification Center (linuxtesting.org) with SVACE.
    
    Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
    Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
    Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
    Link: https://msgid.link/20231211172502.25202-1-dmantipov@yandex.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach [+ + +]
Author: Zheng Wang <zyytlz.wz@163.com>
Date:   Sun Jan 7 08:25:04 2024 +0100

    wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
    
    [ Upstream commit 0f7352557a35ab7888bc7831411ec8a3cbe20d78 ]
    
    This is the candidate patch of CVE-2023-47233 :
    https://nvd.nist.gov/vuln/detail/CVE-2023-47233
    
    In brcm80211 driver,it starts with the following invoking chain
    to start init a timeout worker:
    
    ->brcmf_usb_probe
      ->brcmf_usb_probe_cb
        ->brcmf_attach
          ->brcmf_bus_started
            ->brcmf_cfg80211_attach
              ->wl_init_priv
                ->brcmf_init_escan
                  ->INIT_WORK(&cfg->escan_timeout_work,
                      brcmf_cfg80211_escan_timeout_worker);
    
    If we disconnect the USB by hotplug, it will call
    brcmf_usb_disconnect to make cleanup. The invoking chain is :
    
    brcmf_usb_disconnect
      ->brcmf_usb_disconnect_cb
        ->brcmf_detach
          ->brcmf_cfg80211_detach
            ->kfree(cfg);
    
    While the timeout woker may still be running. This will cause
    a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.
    
    Fix it by deleting the timer and canceling the worker in
    brcmf_cfg80211_detach.
    
    Fixes: e756af5b30b0 ("brcmfmac: add e-scan support.")
    Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
    Cc: stable@vger.kernel.org
    [arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]
    Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
    Signed-off-by: Kalle Valo <kvalo@kernel.org>
    Link: https://msgid.link/20240107072504.392713-1-arend.vanspriel@broadcom.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes [+ + +]
Author: Felix Fietkau <nbd@nbd.name>
Date:   Sat Mar 16 08:43:36 2024 +0100

    wifi: mac80211: check/clear fast rx for non-4addr sta VLAN changes
    
    commit 4f2bdb3c5e3189297e156b3ff84b140423d64685 upstream.
    
    When moving a station out of a VLAN and deleting the VLAN afterwards, the
    fast_rx entry still holds a pointer to the VLAN's netdev, which can cause
    use-after-free bugs. Fix this by immediately calling ieee80211_check_fast_rx
    after the VLAN change.
    
    Cc: stable@vger.kernel.org
    Reported-by: ranygh@riseup.net
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    Link: https://msgid.link/20240316074336.40442-1-nbd@nbd.name
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wireguard: netlink: access device through ctx instead of peer [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Mar 14 16:49:10 2024 -0600

    wireguard: netlink: access device through ctx instead of peer
    
    [ Upstream commit 71cbd32e3db82ea4a74e3ef9aeeaa6971969c86f ]
    
    The previous commit fixed a bug that led to a NULL peer->device being
    dereferenced. It's actually easier and faster performance-wise to
    instead get the device from ctx->wg. This semantically makes more sense
    too, since ctx->wg->peer_allowedips.seq is compared with
    ctx->allowedips_seq, basing them both in ctx. This also acts as a
    defence in depth provision against freed peers.
    
    Cc: stable@vger.kernel.org
    Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

wireguard: netlink: check for dangling peer via is_dead instead of empty list [+ + +]
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Mar 14 16:49:09 2024 -0600

    wireguard: netlink: check for dangling peer via is_dead instead of empty list
    
    [ Upstream commit 55b6c738673871c9b0edae05d0c97995c1ff08c4 ]
    
    If all peers are removed via wg_peer_remove_all(), rather than setting
    peer_list to empty, the peer is added to a temporary list with a head on
    the stack of wg_peer_remove_all(). If a netlink dump is resumed and the
    cursored peer is one that has been removed via wg_peer_remove_all(), it
    will iterate from that peer and then attempt to dump freed peers.
    
    Fix this by instead checking peer->is_dead, which was explictly created
    for this purpose. Also move up the device_update_lock lockdep assertion,
    since reading is_dead relies on that.
    
    It can be reproduced by a small script like:
    
        echo "Setting config..."
        ip link add dev wg0 type wireguard
        wg setconf wg0 /big-config
        (
                while true; do
                        echo "Showing config..."
                        wg showconf wg0 > /dev/null
                done
        ) &
        sleep 4
        wg setconf wg0 <(printf "[Peer]\nPublicKey=$(wg genkey)\n")
    
    Resulting in:
    
        BUG: KASAN: slab-use-after-free in __lock_acquire+0x182a/0x1b20
        Read of size 8 at addr ffff88811956ec70 by task wg/59
        CPU: 2 PID: 59 Comm: wg Not tainted 6.8.0-rc2-debug+ #5
        Call Trace:
         <TASK>
         dump_stack_lvl+0x47/0x70
         print_address_description.constprop.0+0x2c/0x380
         print_report+0xab/0x250
         kasan_report+0xba/0xf0
         __lock_acquire+0x182a/0x1b20
         lock_acquire+0x191/0x4b0
         down_read+0x80/0x440
         get_peer+0x140/0xcb0
         wg_get_device_dump+0x471/0x1130
    
    Cc: stable@vger.kernel.org
    Fixes: e7096c131e51 ("net: WireGuard secure network tunnel")
    Reported-by: Lillian Berry <lillian@star-ark.net>
    Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
    Reviewed-by: Jiri Pirko <jiri@nvidia.com>
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/asm: Add _ASM_RIP() macro for x86-64 (%rip) suffix [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Mar 12 15:40:27 2024 -0700

    x86/asm: Add _ASM_RIP() macro for x86-64 (%rip) suffix
    
    From: "H. Peter Anvin (Intel)" <hpa@zytor.com>
    
    commit f87bc8dc7a7c438c70f97b4e51c76a183313272e upstream.
    
    Add a macro _ASM_RIP() to add a (%rip) suffix on 64 bits only. This is
    useful for immediate memory references where one doesn't want gcc
    to possibly use a register indirection as it may in the case of an "m"
    constraint.
    
    Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Link: https://lkml.kernel.org/r/20210910195910.2542662-3-hpa@zytor.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/bugs: Add asm helpers for executing VERW [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Mar 12 15:40:33 2024 -0700

    x86/bugs: Add asm helpers for executing VERW
    
    commit baf8361e54550a48a7087b603313ad013cc13386 upstream.
    
    MDS mitigation requires clearing the CPU buffers before returning to
    user. This needs to be done late in the exit-to-user path. Current
    location of VERW leaves a possibility of kernel data ending up in CPU
    buffers for memory accesses done after VERW such as:
    
      1. Kernel data accessed by an NMI between VERW and return-to-user can
         remain in CPU buffers since NMI returning to kernel does not
         execute VERW to clear CPU buffers.
      2. Alyssa reported that after VERW is executed,
         CONFIG_GCC_PLUGIN_STACKLEAK=y scrubs the stack used by a system
         call. Memory accesses during stack scrubbing can move kernel stack
         contents into CPU buffers.
      3. When caller saved registers are restored after a return from
         function executing VERW, the kernel stack accesses can remain in
         CPU buffers(since they occur after VERW).
    
    To fix this VERW needs to be moved very late in exit-to-user path.
    
    In preparation for moving VERW to entry/exit asm code, create macros
    that can be used in asm. Also make VERW patching depend on a new feature
    flag X86_FEATURE_CLEAR_CPU_BUF.
    
      [pawan: - Runtime patch jmp instead of verw in macro CLEAR_CPU_BUFFERS
                due to lack of relative addressing support for relocations
                in kernels < v6.5.
              - Add UNWIND_HINT_EMPTY to avoid warning:
                arch/x86/entry/entry.o: warning: objtool: mds_verw_sel+0x0: unreachable instruction]
    
    Reported-by: Alyssa Milburn <alyssa.milburn@intel.com>
    Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Suggested-by: Peter Zijlstra <peterz@infradead.org>
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Link: https://lore.kernel.org/all/20240213-delay-verw-v8-1-a6216d83edb7%40linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/bugs: Fix the SRSO mitigation on Zen3/4 [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Fri Apr 5 16:19:51 2024 +0200

    x86/bugs: Fix the SRSO mitigation on Zen3/4
    
    Commit 4535e1a4174c4111d92c5a9a21e542d232e0fcaa upstream.
    
    The original version of the mitigation would patch in the calls to the
    untraining routines directly.  That is, the alternative() in UNTRAIN_RET
    will patch in the CALL to srso_alias_untrain_ret() directly.
    
    However, even if commit e7c25c441e9e ("x86/cpu: Cleanup the untrain
    mess") meant well in trying to clean up the situation, due to micro-
    architectural reasons, the untraining routine srso_alias_untrain_ret()
    must be the target of a CALL instruction and not of a JMP instruction as
    it is done now.
    
    Reshuffle the alternative macros to accomplish that.
    
    Fixes: e7c25c441e9e ("x86/cpu: Cleanup the untrain mess")
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Reviewed-by: Ingo Molnar <mingo@kernel.org>
    Cc: stable@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/bugs: Use ALTERNATIVE() instead of mds_user_clear static key [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Mar 12 15:40:50 2024 -0700

    x86/bugs: Use ALTERNATIVE() instead of mds_user_clear static key
    
    commit 6613d82e617dd7eb8b0c40b2fe3acea655b1d611 upstream.
    
    The VERW mitigation at exit-to-user is enabled via a static branch
    mds_user_clear. This static branch is never toggled after boot, and can
    be safely replaced with an ALTERNATIVE() which is convenient to use in
    asm.
    
    Switch to ALTERNATIVE() to use the VERW mitigation late in exit-to-user
    path. Also remove the now redundant VERW in exc_nmi() and
    arch_exit_to_user_mode().
    
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Link: https://lore.kernel.org/all/20240213-delay-verw-v8-4-a6216d83edb7%40linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/bugs: Use sysfs_emit() [+ + +]
Author: Borislav Petkov <bp@suse.de>
Date:   Tue Aug 9 17:32:02 2022 +0200

    x86/bugs: Use sysfs_emit()
    
    commit 1d30800c0c0ae1d086ffad2bdf0ba4403370f132 upstream.
    
    Those mitigations are very talkative; use the printing helper which pays
    attention to the buffer size.
    
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lore.kernel.org/r/20220809153419.10182-1-bp@alien8.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/CPU/AMD: Update the Zenbleed microcode revisions [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Fri Mar 15 22:42:27 2024 +0100

    x86/CPU/AMD: Update the Zenbleed microcode revisions
    
    [ Upstream commit 5c84b051bd4e777cf37aaff983277e58c99618d5 ]
    
    Update them to the correct revision numbers.
    
    Fixes: 522b1d69219d ("x86/cpu/amd: Add a Zenbleed fix")
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: <stable@kernel.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/cpu: Enable STIBP on AMD if Automatic IBRS is enabled [+ + +]
Author: Kim Phillips <kim.phillips@amd.com>
Date:   Thu Jul 20 14:47:27 2023 -0500

    x86/cpu: Enable STIBP on AMD if Automatic IBRS is enabled
    
    commit fd470a8beed88440b160d690344fbae05a0b9b1b upstream.
    
    Unlike Intel's Enhanced IBRS feature, AMD's Automatic IBRS does not
    provide protection to processes running at CPL3/user mode, see section
    "Extended Feature Enable Register (EFER)" in the APM v2 at
    https://bugzilla.kernel.org/attachment.cgi?id=304652
    
    Explicitly enable STIBP to protect against cross-thread CPL3
    branch target injections on systems with Automatic IBRS enabled.
    
    Also update the relevant documentation.
    
    Fixes: e7862eda309e ("x86/cpu: Support AMD Automatic IBRS")
    Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
    Signed-off-by: Kim Phillips <kim.phillips@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20230720194727.67022-1-kim.phillips@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/cpu: Support AMD Automatic IBRS [+ + +]
Author: Kim Phillips <kim.phillips@amd.com>
Date:   Tue Jan 24 10:33:18 2023 -0600

    x86/cpu: Support AMD Automatic IBRS
    
    commit e7862eda309ecfccc36bb5558d937ed3ace07f3f upstream.
    
    The AMD Zen4 core supports a new feature called Automatic IBRS.
    
    It is a "set-and-forget" feature that means that, like Intel's Enhanced IBRS,
    h/w manages its IBRS mitigation resources automatically across CPL transitions.
    
    The feature is advertised by CPUID_Fn80000021_EAX bit 8 and is enabled by
    setting MSR C000_0080 (EFER) bit 21.
    
    Enable Automatic IBRS by default if the CPU feature is present.  It typically
    provides greater performance over the incumbent generic retpolines mitigation.
    
    Reuse the SPECTRE_V2_EIBRS spectre_v2_mitigation enum.  AMD Automatic IBRS and
    Intel Enhanced IBRS have similar enablement.  Add NO_EIBRS_PBRSB to
    cpu_vuln_whitelist, since AMD Automatic IBRS isn't affected by PBRSB-eIBRS.
    
    The kernel command line option spectre_v2=eibrs is used to select AMD Automatic
    IBRS, if available.
    
    Signed-off-by: Kim Phillips <kim.phillips@amd.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Sean Christopherson <seanjc@google.com>
    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
    Link: https://lore.kernel.org/r/20230124163319.2277355-8-kim.phillips@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/cpufeatures: Add CPUID_LNX_5 to track recently added Linux-defined word [+ + +]
Author: Sean Christopherson <seanjc@google.com>
Date:   Thu Apr 4 17:16:14 2024 -0700

    x86/cpufeatures: Add CPUID_LNX_5 to track recently added Linux-defined word
    
    commit 8cb4a9a82b21623dbb4b3051dd30d98356cf95bc upstream.
    
    Add CPUID_LNX_5 to track cpufeatures' word 21, and add the appropriate
    compile-time assert in KVM to prevent direct lookups on the features in
    CPUID_LNX_5.  KVM uses X86_FEATURE_* flags to manage guest CPUID, and so
    must translate features that are scattered by Linux from the Linux-defined
    bit to the hardware-defined bit, i.e. should never try to directly access
    scattered features in guest CPUID.
    
    Opportunistically add NR_CPUID_WORDS to enum cpuid_leafs, along with a
    compile-time assert in KVM's CPUID infrastructure to ensure that future
    additions update cpuid_leafs along with NCAPINTS.
    
    No functional change intended.
    
    Fixes: 7f274e609f3d ("x86/cpufeatures: Add new word for scattered features")
    Cc: Sandipan Das <sandipan.das@amd.com>
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/cpufeatures: Add new word for scattered features [+ + +]
Author: Sandipan Das <sandipan.das@amd.com>
Date:   Mon Mar 25 13:01:44 2024 +0530

    x86/cpufeatures: Add new word for scattered features
    
    commit 7f274e609f3d5f45c22b1dd59053f6764458b492 upstream.
    
    Add a new word for scattered features because all free bits among the
    existing Linux-defined auxiliary flags have been exhausted.
    
    Signed-off-by: Sandipan Das <sandipan.das@amd.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/8380d2a0da469a1f0ad75b8954a79fb689599ff6.1711091584.git.sandipan.das@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/entry_32: Add VERW just before userspace transition [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Mar 12 15:40:44 2024 -0700

    x86/entry_32: Add VERW just before userspace transition
    
    commit a0e2dab44d22b913b4c228c8b52b2a104434b0b3 upstream.
    
    As done for entry_64, add support for executing VERW late in exit to
    user path for 32-bit mode.
    
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Link: https://lore.kernel.org/all/20240213-delay-verw-v8-3-a6216d83edb7%40linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/entry_64: Add VERW just before userspace transition [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Mar 12 15:40:39 2024 -0700

    x86/entry_64: Add VERW just before userspace transition
    
    commit 3c7501722e6b31a6e56edd23cea5e77dbb9ffd1a upstream.
    
    Mitigation for MDS is to use VERW instruction to clear any secrets in
    CPU Buffers. Any memory accesses after VERW execution can still remain
    in CPU buffers. It is safer to execute VERW late in return to user path
    to minimize the window in which kernel data can end up in CPU buffers.
    There are not many kernel secrets to be had after SWITCH_TO_USER_CR3.
    
    Add support for deploying VERW mitigation after user register state is
    restored. This helps minimize the chances of kernel data ending up into
    CPU buffers after executing VERW.
    
    Note that the mitigation at the new location is not yet enabled.
    
      Corner case not handled
      =======================
      Interrupts returning to kernel don't clear CPUs buffers since the
      exit-to-user path is expected to do that anyways. But, there could be
      a case when an NMI is generated in kernel after the exit-to-user path
      has cleared the buffers. This case is not handled and NMI returning to
      kernel don't clear CPU buffers because:
    
      1. It is rare to get an NMI after VERW, but before returning to user.
      2. For an unprivileged user, there is no known way to make that NMI
         less rare or target it.
      3. It would take a large number of these precisely-timed NMIs to mount
         an actual attack.  There's presumably not enough bandwidth.
      4. The NMI in question occurs after a VERW, i.e. when user state is
         restored and most interesting data is already scrubbed. Whats left
         is only the data that NMI touches, and that may or may not be of
         any interest.
    
      [ pawan: resolved conflict in syscall_return_via_sysret, added
               CLEAR_CPU_BUFFERS to USERGS_SYSRET64 ]
    
    Suggested-by: Dave Hansen <dave.hansen@intel.com>
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Link: https://lore.kernel.org/all/20240213-delay-verw-v8-2-a6216d83edb7%40linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/head/64: Re-enable stack protection [+ + +]
Author: Michael Roth <michael.roth@amd.com>
Date:   Wed Feb 9 12:10:17 2022 -0600

    x86/head/64: Re-enable stack protection
    
    commit 469693d8f62299709e8ba56d8fb3da9ea990213c upstream.
    
    Due to
    
      103a4908ad4d ("x86/head/64: Disable stack protection for head$(BITS).o")
    
    kernel/head{32,64}.c are compiled with -fno-stack-protector to allow
    a call to set_bringup_idt_handler(), which would otherwise have stack
    protection enabled with CONFIG_STACKPROTECTOR_STRONG.
    
    While sufficient for that case, there may still be issues with calls to
    any external functions that were compiled with stack protection enabled
    that in-turn make stack-protected calls, or if the exception handlers
    set up by set_bringup_idt_handler() make calls to stack-protected
    functions.
    
    Subsequent patches for SEV-SNP CPUID validation support will introduce
    both such cases. Attempting to disable stack protection for everything
    in scope to address that is prohibitive since much of the code, like the
    SEV-ES #VC handler, is shared code that remains in use after boot and
    could benefit from having stack protection enabled. Attempting to inline
    calls is brittle and can quickly balloon out to library/helper code
    where that's not really an option.
    
    Instead, re-enable stack protection for head32.c/head64.c, and make the
    appropriate changes to ensure the segment used for the stack canary is
    initialized in advance of any stack-protected C calls.
    
    For head64.c:
    
    - The BSP will enter from startup_64() and call into C code
      (startup_64_setup_env()) shortly after setting up the stack, which
      may result in calls to stack-protected code. Set up %gs early to allow
      for this safely.
    - APs will enter from secondary_startup_64*(), and %gs will be set up
      soon after. There is one call to C code prior to %gs being setup
      (__startup_secondary_64()), but it is only to fetch 'sme_me_mask'
      global, so just load 'sme_me_mask' directly instead, and remove the
      now-unused __startup_secondary_64() function.
    
    For head32.c:
    
    - BSPs/APs will set %fs to __BOOT_DS prior to any C calls. In recent
      kernels, the compiler is configured to access the stack canary at
      %fs:__stack_chk_guard [1], which overlaps with the initial per-cpu
      '__stack_chk_guard' variable in the initial/"master" .data..percpu
      area. This is sufficient to allow access to the canary for use
      during initial startup, so no changes are needed there.
    
    [1] 3fb0fdb3bbe7 ("x86/stackprotector/32: Make the canary into a regular percpu variable")
    
      [ bp: Massage commit message. ]
    
    Suggested-by: Joerg Roedel <jroedel@suse.de> #for 64-bit %gs set up
    Signed-off-by: Michael Roth <michael.roth@amd.com>
    Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lore.kernel.org/r/20220307213356.2797205-24-brijesh.singh@amd.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/mce: Make sure to grab mce_sysfs_mutex in set_bank() [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Wed Mar 13 14:48:27 2024 +0100

    x86/mce: Make sure to grab mce_sysfs_mutex in set_bank()
    
    commit 3ddf944b32f88741c303f0b21459dbb3872b8bc5 upstream.
    
    Modifying a MCA bank's MCA_CTL bits which control which error types to
    be reported is done over
    
      /sys/devices/system/machinecheck/
      ├── machinecheck0
      │   ├── bank0
      │   ├── bank1
      │   ├── bank10
      │   ├── bank11
      ...
    
    sysfs nodes by writing the new bit mask of events to enable.
    
    When the write is accepted, the kernel deletes all current timers and
    reinits all banks.
    
    Doing that in parallel can lead to initializing a timer which is already
    armed and in the timer wheel, i.e., in use already:
    
      ODEBUG: init active (active state 0) object: ffff888063a28000 object
      type: timer_list hint: mce_timer_fn+0x0/0x240 arch/x86/kernel/cpu/mce/core.c:2642
      WARNING: CPU: 0 PID: 8120 at lib/debugobjects.c:514
      debug_print_object+0x1a0/0x2a0 lib/debugobjects.c:514
    
    Fix that by grabbing the sysfs mutex as the rest of the MCA sysfs code
    does.
    
    Reported by: Yue Sun <samsun1006219@gmail.com>
    Reported by: xingwei lee <xrivendell7@gmail.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: <stable@kernel.org>
    Link: https://lore.kernel.org/r/CAEkJfYNiENwQY8yV1LYJ9LjJs%2Bx_-PqMv98gKig55=2vbzffRw@mail.gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/mm/pat: fix VM_PAT handling in COW mappings [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Wed Apr 3 23:21:30 2024 +0200

    x86/mm/pat: fix VM_PAT handling in COW mappings
    
    commit 04c35ab3bdae7fefbd7c7a7355f29fa03a035221 upstream.
    
    PAT handling won't do the right thing in COW mappings: the first PTE (or,
    in fact, all PTEs) can be replaced during write faults to point at anon
    folios.  Reliably recovering the correct PFN and cachemode using
    follow_phys() from PTEs will not work in COW mappings.
    
    Using follow_phys(), we might just get the address+protection of the anon
    folio (which is very wrong), or fail on swap/nonswap entries, failing
    follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
    track_pfn_copy(), not properly calling free_pfn_range().
    
    In free_pfn_range(), we either wouldn't call memtype_free() or would call
    it with the wrong range, possibly leaking memory.
    
    To fix that, let's update follow_phys() to refuse returning anon folios,
    and fallback to using the stored PFN inside vma->vm_pgoff for COW mappings
    if we run into that.
    
    We will now properly handle untrack_pfn() with COW mappings, where we
    don't need the cachemode.  We'll have to fail fork()->track_pfn_copy() if
    the first page was replaced by an anon folio, though: we'd have to store
    the cachemode in the VMA to make this work, likely growing the VMA size.
    
    For now, lets keep it simple and let track_pfn_copy() just fail in that
    case: it would have failed in the past with swap/nonswap entries already,
    and it would have done the wrong thing with anon folios.
    
    Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
    
    <--- C reproducer --->
     #include <stdio.h>
     #include <sys/mman.h>
     #include <unistd.h>
     #include <liburing.h>
    
     int main(void)
     {
             struct io_uring_params p = {};
             int ring_fd;
             size_t size;
             char *map;
    
             ring_fd = io_uring_setup(1, &p);
             if (ring_fd < 0) {
                     perror("io_uring_setup");
                     return 1;
             }
             size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
    
             /* Map the submission queue ring MAP_PRIVATE */
             map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
                        ring_fd, IORING_OFF_SQ_RING);
             if (map == MAP_FAILED) {
                     perror("mmap");
                     return 1;
             }
    
             /* We have at least one page. Let's COW it. */
             *map = 0;
             pause();
             return 0;
     }
    <--- C reproducer --->
    
    On a system with 16 GiB RAM and swap configured:
     # ./iouring &
     # memhog 16G
     # killall iouring
    [  301.552930] ------------[ cut here ]------------
    [  301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100
    [  301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g
    [  301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1
    [  301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4
    [  301.559569] RIP: 0010:untrack_pfn+0xf4/0x100
    [  301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000
    [  301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282
    [  301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047
    [  301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200
    [  301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000
    [  301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000
    [  301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000
    [  301.564186] FS:  0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000
    [  301.564773] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0
    [  301.565725] PKRU: 55555554
    [  301.565944] Call Trace:
    [  301.566148]  <TASK>
    [  301.566325]  ? untrack_pfn+0xf4/0x100
    [  301.566618]  ? __warn+0x81/0x130
    [  301.566876]  ? untrack_pfn+0xf4/0x100
    [  301.567163]  ? report_bug+0x171/0x1a0
    [  301.567466]  ? handle_bug+0x3c/0x80
    [  301.567743]  ? exc_invalid_op+0x17/0x70
    [  301.568038]  ? asm_exc_invalid_op+0x1a/0x20
    [  301.568363]  ? untrack_pfn+0xf4/0x100
    [  301.568660]  ? untrack_pfn+0x65/0x100
    [  301.568947]  unmap_single_vma+0xa6/0xe0
    [  301.569247]  unmap_vmas+0xb5/0x190
    [  301.569532]  exit_mmap+0xec/0x340
    [  301.569801]  __mmput+0x3e/0x130
    [  301.570051]  do_exit+0x305/0xaf0
    ...
    
    Link: https://lkml.kernel.org/r/20240403212131.929421-3-david@redhat.com
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Reported-by: Wupeng Ma <mawupeng1@huawei.com>
    Closes: https://lkml.kernel.org/r/20240227122814.3781907-1-mawupeng1@huawei.com
    Fixes: b1a86e15dc03 ("x86, pat: remove the dependency on 'vm_pgoff' in track/untrack pfn vma routines")
    Fixes: 5899329b1910 ("x86: PAT: implement track/untrack of pfnmap regions for x86 - v3")
    Acked-by: Ingo Molnar <mingo@kernel.org>
    Cc: Dave Hansen <dave.hansen@linux.intel.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/mmio: Disable KVM mitigation when X86_FEATURE_CLEAR_CPU_BUF is set [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Mar 12 15:41:07 2024 -0700

    x86/mmio: Disable KVM mitigation when X86_FEATURE_CLEAR_CPU_BUF is set
    
    commit e95df4ec0c0c9791941f112db699fae794b9862a upstream.
    
    Currently MMIO Stale Data mitigation for CPUs not affected by MDS/TAA is
    to only deploy VERW at VMentry by enabling mmio_stale_data_clear static
    branch. No mitigation is needed for kernel->user transitions. If such
    CPUs are also affected by RFDS, its mitigation may set
    X86_FEATURE_CLEAR_CPU_BUF to deploy VERW at kernel->user and VMentry.
    This could result in duplicate VERW at VMentry.
    
    Fix this by disabling mmio_stale_data_clear static branch when
    X86_FEATURE_CLEAR_CPU_BUF is enabled.
    
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/pm: Work around false positive kmemleak report in msr_build_context() [+ + +]
Author: Anton Altaparmakov <anton@tuxera.com>
Date:   Thu Mar 14 14:26:56 2024 +0000

    x86/pm: Work around false positive kmemleak report in msr_build_context()
    
    [ Upstream commit e3f269ed0accbb22aa8f25d2daffa23c3fccd407 ]
    
    Since:
    
      7ee18d677989 ("x86/power: Make restore_processor_context() sane")
    
    kmemleak reports this issue:
    
      unreferenced object 0xf68241e0 (size 32):
        comm "swapper/0", pid 1, jiffies 4294668610 (age 68.432s)
        hex dump (first 32 bytes):
          00 cc cc cc 29 10 01 c0 00 00 00 00 00 00 00 00  ....)...........
          00 42 82 f6 cc cc cc cc cc cc cc cc cc cc cc cc  .B..............
        backtrace:
          [<461c1d50>] __kmem_cache_alloc_node+0x106/0x260
          [<ea65e13b>] __kmalloc+0x54/0x160
          [<c3858cd2>] msr_build_context.constprop.0+0x35/0x100
          [<46635aff>] pm_check_save_msr+0x63/0x80
          [<6b6bb938>] do_one_initcall+0x41/0x1f0
          [<3f3add60>] kernel_init_freeable+0x199/0x1e8
          [<3b538fde>] kernel_init+0x1a/0x110
          [<938ae2b2>] ret_from_fork+0x1c/0x28
    
    Which is a false positive.
    
    Reproducer:
    
      - Run rsync of whole kernel tree (multiple times if needed).
      - start a kmemleak scan
      - Note this is just an example: a lot of our internal tests hit these.
    
    The root cause is similar to the fix in:
    
      b0b592cf0836 x86/pm: Fix false positive kmemleak report in msr_build_context()
    
    ie. the alignment within the packed struct saved_context
    which has everything unaligned as there is only "u16 gs;" at start of
    struct where in the past there were four u16 there thus aligning
    everything afterwards.  The issue is with the fact that Kmemleak only
    searches for pointers that are aligned (see how pointers are scanned in
    kmemleak.c) so when the struct members are not aligned it doesn't see
    them.
    
    Testing:
    
    We run a lot of tests with our CI, and after applying this fix we do not
    see any kmemleak issues any more whilst without it we see hundreds of
    the above report. From a single, simple test run consisting of 416 individual test
    cases on kernel 5.10 x86 with kmemleak enabled we got 20 failures due to this,
    which is quite a lot. With this fix applied we get zero kmemleak related failures.
    
    Fixes: 7ee18d677989 ("x86/power: Make restore_processor_context() sane")
    Signed-off-by: Anton Altaparmakov <anton@tuxera.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: "Rafael J. Wysocki" <rafael@kernel.org>
    Cc: stable@vger.kernel.org
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: https://lore.kernel.org/r/20240314142656.17699-1-anton@tuxera.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
x86/retpoline: Add NOENDBR annotation to the SRSO dummy return thunk [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Fri Apr 5 16:46:37 2024 +0200

    x86/retpoline: Add NOENDBR annotation to the SRSO dummy return thunk
    
    commit b377c66ae3509ccea596512d6afb4777711c4870 upstream.
    
    srso_alias_untrain_ret() is special code, even if it is a dummy
    which is called in the !SRSO case, so annotate it like its real
    counterpart, to address the following objtool splat:
    
      vmlinux.o: warning: objtool: .export_symbol+0x2b290: data relocation to !ENDBR: srso_alias_untrain_ret+0x0
    
    Fixes: 4535e1a4174c ("x86/bugs: Fix the SRSO mitigation on Zen3/4")
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Link: https://lore.kernel.org/r/20240405144637.17908-1-bp@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

x86/retpoline: Do the necessary fixup to the Zen3/4 srso return thunk for !SRSO [+ + +]
Author: Borislav Petkov (AMD) <bp@alien8.de>
Date:   Fri Apr 5 16:20:35 2024 +0200

    x86/retpoline: Do the necessary fixup to the Zen3/4 srso return thunk for !SRSO
    
    Commit 0e110732473e14d6520e49d75d2c88ef7d46fe67 upstream.
    
    The srso_alias_untrain_ret() dummy thunk in the !CONFIG_MITIGATION_SRSO
    case is there only for the altenative in CALL_UNTRAIN_RET to have
    a symbol to resolve.
    
    However, testing with kernels which don't have CONFIG_MITIGATION_SRSO
    enabled, leads to the warning in patch_return() to fire:
    
      missing return thunk: srso_alias_untrain_ret+0x0/0x10-0x0: eb 0e 66 66 2e
      WARNING: CPU: 0 PID: 0 at arch/x86/kernel/alternative.c:826 apply_returns (arch/x86/kernel/alternative.c:826
    
    Put in a plain "ret" there so that gcc doesn't put a return thunk in
    in its place which special and gets checked.
    
    In addition:
    
      ERROR: modpost: "srso_alias_untrain_ret" [arch/x86/kvm/kvm-amd.ko] undefined!
      make[2]: *** [scripts/Makefile.modpost:145: Module.symvers] Chyba 1
      make[1]: *** [/usr/src/linux-6.8.3/Makefile:1873: modpost] Chyba 2
      make: *** [Makefile:240: __sub-make] Chyba 2
    
    since !SRSO builds would use the dummy return thunk as reported by
    petr.pisar@atlas.cz, https://bugzilla.kernel.org/show_bug.cgi?id=218679.
    
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Closes: https://lore.kernel.org/oe-lkp/202404020901.da75a60f-oliver.sang@intel.com
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Link: https://lore.kernel.org/all/202404020901.da75a60f-oliver.sang@intel.com/
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/rfds: Mitigate Register File Data Sampling (RFDS) [+ + +]
Author: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Date:   Tue Mar 12 15:41:19 2024 -0700

    x86/rfds: Mitigate Register File Data Sampling (RFDS)
    
    commit 8076fcde016c9c0e0660543e67bff86cb48a7c9c upstream.
    
    RFDS is a CPU vulnerability that may allow userspace to infer kernel
    stale data previously used in floating point registers, vector registers
    and integer registers. RFDS only affects certain Intel Atom processors.
    
    Intel released a microcode update that uses VERW instruction to clear
    the affected CPU buffers. Unlike MDS, none of the affected cores support
    SMT.
    
    Add RFDS bug infrastructure and enable the VERW based mitigation by
    default, that clears the affected buffers just before exiting to
    userspace. Also add sysfs reporting and cmdline parameter
    "reg_file_data_sampling" to control the mitigation.
    
    For details see:
    Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst
    
      [ pawan: - Resolved conflicts in sysfs reporting.
               - s/ATOM_GRACEMONT/ALDERLAKE_N/ATOM_GRACEMONT is called
                 ALDERLAKE_N in 6.6. ]
    
    Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
    Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/srso: Add SRSO mitigation for Hygon processors [+ + +]
Author: Pu Wen <puwen@hygon.cn>
Date:   Thu Sep 28 14:59:16 2023 +0800

    x86/srso: Add SRSO mitigation for Hygon processors
    
    commit a5ef7d68cea1344cf524f04981c2b3f80bedbb0d upstream.
    
    Add mitigation for the speculative return stack overflow vulnerability
    which exists on Hygon processors too.
    
    Signed-off-by: Pu Wen <puwen@hygon.cn>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/tencent_4A14812842F104E93AA722EC939483CEFF05@qq.com
    Signed-off-by: Ashwin Dayanand Kamat <ashwin.kamat@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
x86/stackprotector/32: Make the canary into a regular percpu variable [+ + +]
Author: Andy Lutomirski <luto@kernel.org>
Date:   Sat Feb 13 11:19:44 2021 -0800

    x86/stackprotector/32: Make the canary into a regular percpu variable
    
    [ Upstream commit 3fb0fdb3bbe7aed495109b3296b06c2409734023 ]
    
    On 32-bit kernels, the stackprotector canary is quite nasty -- it is
    stored at %gs:(20), which is nasty because 32-bit kernels use %fs for
    percpu storage.  It's even nastier because it means that whether %gs
    contains userspace state or kernel state while running kernel code
    depends on whether stackprotector is enabled (this is
    CONFIG_X86_32_LAZY_GS), and this setting radically changes the way
    that segment selectors work.  Supporting both variants is a
    maintenance and testing mess.
    
    Merely rearranging so that percpu and the stack canary
    share the same segment would be messy as the 32-bit percpu address
    layout isn't currently compatible with putting a variable at a fixed
    offset.
    
    Fortunately, GCC 8.1 added options that allow the stack canary to be
    accessed as %fs:__stack_chk_guard, effectively turning it into an ordinary
    percpu variable.  This lets us get rid of all of the code to manage the
    stack canary GDT descriptor and the CONFIG_X86_32_LAZY_GS mess.
    
    (That name is special.  We could use any symbol we want for the
     %fs-relative mode, but for CONFIG_SMP=n, gcc refuses to let us use any
     name other than __stack_chk_guard.)
    
    Forcibly disable stackprotector on older compilers that don't support
    the new options and turn the stack canary into a percpu variable. The
    "lazy GS" approach is now used for all 32-bit configurations.
    
    Also makes load_gs_index() work on 32-bit kernels. On 64-bit kernels,
    it loads the GS selector and updates the user GSBASE accordingly. (This
    is unchanged.) On 32-bit kernels, it loads the GS selector and updates
    GSBASE, which is now always the user base. This means that the overall
    effect is the same on 32-bit and 64-bit, which avoids some ifdeffery.
    
     [ bp: Massage commit message. ]
    
    Signed-off-by: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: Borislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/c0ff7dba14041c7e5d1cae5d4df052f03759bef3.1613243844.git.luto@kernel.org
    Stable-dep-of: e3f269ed0acc ("x86/pm: Work around false positive kmemleak report in msr_build_context()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
xen/events: close evtchn after mapping cleanup [+ + +]
Author: Maximilian Heyne <mheyne@amazon.de>
Date:   Wed Jan 24 16:31:28 2024 +0000

    xen/events: close evtchn after mapping cleanup
    
    commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream.
    
    shutdown_pirq and startup_pirq are not taking the
    irq_mapping_update_lock because they can't due to lock inversion. Both
    are called with the irq_desc->lock being taking. The lock order,
    however, is first irq_mapping_update_lock and then irq_desc->lock.
    
    This opens multiple races:
    - shutdown_pirq can be interrupted by a function that allocates an event
      channel:
    
      CPU0                        CPU1
      shutdown_pirq {
        xen_evtchn_close(e)
                                  __startup_pirq {
                                    EVTCHNOP_bind_pirq
                                      -> returns just freed evtchn e
                                    set_evtchn_to_irq(e, irq)
                                  }
        xen_irq_info_cleanup() {
          set_evtchn_to_irq(e, -1)
        }
      }
    
      Assume here event channel e refers here to the same event channel
      number.
      After this race the evtchn_to_irq mapping for e is invalid (-1).
    
    - __startup_pirq races with __unbind_from_irq in a similar way. Because
      __startup_pirq doesn't take irq_mapping_update_lock it can grab the
      evtchn that __unbind_from_irq is currently freeing and cleaning up. In
      this case even though the event channel is allocated, its mapping can
      be unset in evtchn_to_irq.
    
    The fix is to first cleanup the mappings and then close the event
    channel. In this way, when an event channel gets allocated it's
    potential previous evtchn_to_irq mappings are guaranteed to be unset already.
    This is also the reverse order of the allocation where first the event
    channel is allocated and then the mappings are setup.
    
    On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal
    [un]bind interfaces"), we hit a BUG like the following during probing of NVMe
    devices. The issue is that during nvme_setup_io_queues, pci_free_irq
    is called for every device which results in a call to shutdown_pirq.
    With many nvme devices it's therefore likely to hit this race during
    boot because there will be multiple calls to shutdown_pirq and
    startup_pirq are running potentially in parallel.
    
      ------------[ cut here ]------------
      blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled
      kernel BUG at drivers/xen/events/events_base.c:499!
      invalid opcode: 0000 [#1] SMP PTI
      CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1
      Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006
      Workqueue: nvme-reset-wq nvme_reset_work
      RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0
      Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00
      RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046
      RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006
      RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff
      RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00
      R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed
      R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002
      FS:  0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       ? show_trace_log_lvl+0x1c1/0x2d9
       ? show_trace_log_lvl+0x1c1/0x2d9
       ? set_affinity_irq+0xdc/0x1c0
       ? __die_body.cold+0x8/0xd
       ? die+0x2b/0x50
       ? do_trap+0x90/0x110
       ? bind_evtchn_to_cpu+0xdf/0xf0
       ? do_error_trap+0x65/0x80
       ? bind_evtchn_to_cpu+0xdf/0xf0
       ? exc_invalid_op+0x4e/0x70
       ? bind_evtchn_to_cpu+0xdf/0xf0
       ? asm_exc_invalid_op+0x12/0x20
       ? bind_evtchn_to_cpu+0xdf/0xf0
       ? bind_evtchn_to_cpu+0xc5/0xf0
       set_affinity_irq+0xdc/0x1c0
       irq_do_set_affinity+0x1d7/0x1f0
       irq_setup_affinity+0xd6/0x1a0
       irq_startup+0x8a/0xf0
       __setup_irq+0x639/0x6d0
       ? nvme_suspend+0x150/0x150
       request_threaded_irq+0x10c/0x180
       ? nvme_suspend+0x150/0x150
       pci_request_irq+0xa8/0xf0
       ? __blk_mq_free_request+0x74/0xa0
       queue_request_irq+0x6f/0x80
       nvme_create_queue+0x1af/0x200
       nvme_create_io_queues+0xbd/0xf0
       nvme_setup_io_queues+0x246/0x320
       ? nvme_irq_check+0x30/0x30
       nvme_reset_work+0x1c8/0x400
       process_one_work+0x1b0/0x350
       worker_thread+0x49/0x310
       ? process_one_work+0x350/0x350
       kthread+0x11b/0x140
       ? __kthread_bind_mask+0x60/0x60
       ret_from_fork+0x22/0x30
      Modules linked in:
      ---[ end trace a11715de1eee1873 ]---
    
    Fixes: d46a78b05c0e ("xen: implement pirq type event channels")
    Cc: stable@vger.kernel.org
    Co-debugged-by: Andrew Panyakin <apanyaki@amazon.com>
    Signed-off-by: Maximilian Heyne <mheyne@amazon.de>
    Reviewed-by: Juergen Gross <jgross@suse.com>
    Link: https://lore.kernel.org/r/20240124163130.31324-1-mheyne@amazon.de
    Signed-off-by: Juergen Gross <jgross@suse.com>
    [apanyaki: backport to v5.10-stable]
    Signed-off-by: Andrew Paniakin <apanyaki@amazon.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
xfrm: Avoid clang fortify warning in copy_to_user_tmpl() [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Wed Feb 21 14:46:21 2024 -0700

    xfrm: Avoid clang fortify warning in copy_to_user_tmpl()
    
    commit 1a807e46aa93ebad1dfbed4f82dc3bf779423a6e upstream.
    
    After a couple recent changes in LLVM, there is a warning (or error with
    CONFIG_WERROR=y or W=e) from the compile time fortify source routines,
    specifically the memset() in copy_to_user_tmpl().
    
      In file included from net/xfrm/xfrm_user.c:14:
      ...
      include/linux/fortify-string.h:438:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
        438 |                         __write_overflow_field(p_size_field, size);
            |                         ^
      1 error generated.
    
    While ->xfrm_nr has been validated against XFRM_MAX_DEPTH when its value
    is first assigned in copy_templates() by calling validate_tmpl() first
    (so there should not be any issue in practice), LLVM/clang cannot really
    deduce that across the boundaries of these functions. Without that
    knowledge, it cannot assume that the loop stops before i is greater than
    XFRM_MAX_DEPTH, which would indeed result a stack buffer overflow in the
    memset().
    
    To make the bounds of ->xfrm_nr clear to the compiler and add additional
    defense in case copy_to_user_tmpl() is ever used in a path where
    ->xfrm_nr has not been properly validated against XFRM_MAX_DEPTH first,
    add an explicit bound check and early return, which clears up the
    warning.
    
    Cc: stable@vger.kernel.org
    Link: https://github.com/ClangBuiltLinux/linux/issues/1985
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Reviewed-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>