Linux 5.4.274

 
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: 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>

 
ARM: dts: mmp2-brownstone: Don't redeclare phandle references [+ + +]
Author: Lubomir Rintel <lkundrak@v3.sk>
Date:   Fri Mar 20 18:41:01 2020 +0100

    ARM: dts: mmp2-brownstone: Don't redeclare phandle references
    
    [ Upstream commit 5a56cf3e8738f5d31d8c024d0c62a4c2bfe76fb2 ]
    
    Extend the nodes by their phandle references instead of recreating the
    tree and declaring references of the same names.
    
    Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
    Reviewed-by: Rob Herring <robh@kernel.org>
    Link: https://lore.kernel.org/r/20200320174107.29406-5-lkundrak@v3.sk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 831e0cd4f9ee ("arm: dts: marvell: Fix maxium->maxim typo in brownstone dts")
    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: 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
    
    commit f2d5dcb48f7ba9e3ff249d58fc1fa963d374e66a upstream.
    
    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: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
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-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>

 
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: 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>

 
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/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/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/vkms: call drm_atomic_helper_shutdown before drm_dev_put() [+ + +]
Author: Guo Mengqi <guomengqi3@huawei.com>
Date:   Tue Apr 9 10:26:47 2024 +0800

    drm/vkms: call drm_atomic_helper_shutdown before drm_dev_put()
    
    commit 73a82b22963d ("drm/atomic: Fix potential use-after-free
    in nonblocking commits") introduced drm_dev_get/put() to
    drm_atomic_helper_shutdown(). And this cause problem in vkms driver exit
    process.
    
    vkms_exit()
      drm_dev_put()
        vkms_release()
          drm_atomic_helper_shutdown()
            drm_dev_get()
            drm_dev_put()
              vkms_release()    ------ use after free
    
    Using 5.4 stable x86 image on qemu, below stacktrace can be triggered by
    load and unload vkms.ko.
    
    root:~ # insmod vkms.ko
    [   76.957802] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
    [   76.961490] [drm] Driver supports precise vblank timestamp query.
    [   76.964416] [drm] Initialized vkms 1.0.0 20180514 for vkms on minor 0
    root:~ # rmmod vkms.ko
    [   79.650202] refcount_t: addition on 0; use-after-free.
    [   79.650249] WARNING: CPU: 2 PID: 3533 at ../lib/refcount.c:25 refcount_warn_saturate+0xcf/0xf0
    [   79.654241] Modules linked in: vkms(-)
    [   79.654249] CPU: 2 PID: 3533 Comm: rmmod Not tainted 5.4.273 #4
    [   79.654251] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
    [   79.654262] RIP: 0010:refcount_warn_saturate+0xcf/0xf0
    ...
    [   79.654296] Call Trace:
    [   79.654462]  ? __warn+0x80/0xd0
    [   79.654473]  ? refcount_warn_saturate+0xcf/0xf0
    [   79.654481]  ? report_bug+0xb6/0x130
    [   79.654484]  ? refcount_warn_saturate+0xcf/0xf0
    [   79.654489]  ? fixup_bug.part.12+0x13/0x30
    [   79.654492]  ? do_error_trap+0x90/0xb0
    [   79.654495]  ? do_invalid_op+0x31/0x40
    [   79.654497]  ? refcount_warn_saturate+0xcf/0xf0
    [   79.654504]  ? invalid_op+0x1e/0x30
    [   79.654508]  ? refcount_warn_saturate+0xcf/0xf0
    [   79.654516]  drm_atomic_state_init+0x68/0xb0
    [   79.654543]  drm_atomic_state_alloc+0x43/0x60
    [   79.654551]  drm_atomic_helper_disable_all+0x13/0x180
    [   79.654562]  drm_atomic_helper_shutdown+0x5f/0xb0
    [   79.654571]  vkms_release+0x18/0x40 [vkms]
    [   79.654575]  vkms_exit+0x29/0xc00 [vkms]
    [   79.654582]  __x64_sys_delete_module+0x155/0x220
    [   79.654592]  do_syscall_64+0x43/0x120
    [   79.654603]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1
    [   79.654619] ---[ end trace ce0c02f57ea6bf73 ]---
    
    It seems that the proper unload sequence is:
            drm_atomic_helper_shutdown();
            drm_dev_put();
    
    Just put drm_atomic_helper_shutdown() before drm_dev_put()
    should solve the problem.
    
    Note that vkms exit code is refactored by commit 53d77aaa3f76
    ("drm/vkms: Use devm_drm_dev_alloc") in tags/v5.10-rc1.
    
    So this bug only exists on 4.19 and 5.4.
    
    Fixes: 380c7ceabdde ("drm/atomic: Fix potential use-after-free in nonblocking commits")
    Fixes: 2ead1be54b22 ("drm/vkms: Fix connector leak at the module removal")
    Signed-off-by: Guo Mengqi <guomengqi3@huawei.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: Add type I version 0 support. [+ + +]
Author: William Tu <u9012063@gmail.com>
Date:   Tue May 5 09:05:06 2020 -0700

    erspan: Add type I version 0 support.
    
    [ Upstream commit f989d546a2d5a9f001f6f8be49d98c10ab9b1897 ]
    
    The Type I ERSPAN frame format is based on the barebones
    IP + GRE(4-byte) encapsulation on top of the raw mirrored frame.
    Both type I and II use 0x88BE as protocol type. Unlike type II
    and III, no sequence number or key is required.
    To creat a type I erspan tunnel device:
      $ ip link add dev erspan11 type erspan \
                local 172.16.1.100 remote 172.16.1.200 \
                erspan_ver 0
    
    Signed-off-by: William Tu <u9012063@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Stable-dep-of: 17af420545a7 ("erspan: make sure erspan_base_hdr is present in skb->head")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

erspan: Check IFLA_GRE_ERSPAN_VER is set. [+ + +]
Author: William Tu <u9012063@gmail.com>
Date:   Tue May 12 10:36:23 2020 -0700

    erspan: Check IFLA_GRE_ERSPAN_VER is set.
    
    commit 51fa960d3b5163b1af22efdebcabfccc5d615ad6 upstream.
    
    Add a check to make sure the IFLA_GRE_ERSPAN_VER is provided by users.
    
    Fixes: f989d546a2d5 ("erspan: Add type I version 0 support.")
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: William Tu <u9012063@gmail.com>
    Reviewed-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    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
    
    [ Upstream commit 17af420545a750f763025149fa7b833a4fc8b8f0 ]
    
    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: Sasha Levin <sashal@kernel.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: 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>

 
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>

 
firmware: meson_sm: fix to avoid potential NULL pointer dereference [+ + +]
Author: Zhang Shurong <zhang_shurong@foxmail.com>
Date:   Sat Jul 15 22:13:38 2023 +0800

    firmware: meson_sm: fix to avoid potential NULL pointer dereference
    
    commit f2ed165619c16577c02b703a114a1f6b52026df4 upstream.
    
    of_match_device() may fail and returns a NULL pointer.
    
    Fix this by checking the return value of of_match_device.
    
    Fixes: 8cde3c2153e8 ("firmware: meson_sm: Rework driver as a proper platform driver")
    Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com>
    Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
    Link: https://lore.kernel.org/r/tencent_AA08AAA6C4F34D53ADCE962E188A879B8206@qq.com
    Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

firmware: meson_sm: Rework driver as a proper platform driver [+ + +]
Author: Carlo Caione <ccaione@baylibre.com>
Date:   Wed Jul 31 09:23:39 2019 +0100

    firmware: meson_sm: Rework driver as a proper platform driver
    
    [ Upstream commit 8cde3c2153e8f57be884c0e73f18bc4de150e870 ]
    
    The secure monitor driver is currently a frankenstein driver which is
    registered as a platform driver but its functionality goes through a
    global struct accessed by the consumer drivers using exported helper
    functions.
    
    Try to tidy up the driver moving the firmware struct into the driver
    data and make the consumer drivers referencing the secure-monitor using
    a new property in the DT.
    
    Currently only the nvmem driver is using this API so we can fix it in
    the same commit.
    
    Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
    Signed-off-by: Carlo Caione <ccaione@baylibre.com>
    Signed-off-by: Kevin Hilman <khilman@baylibre.com>
    Stable-dep-of: cbd38332c140 ("nvmem: meson-efuse: fix function pointer type mismatch")
    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>

 
fs: add a vfs_fchmod helper [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue Jul 14 08:55:05 2020 +0200

    fs: add a vfs_fchmod helper
    
    [ Upstream commit 9e96c8c0e94eea2f69a9705f5d0f51928ea26c17 ]
    
    Add a helper for struct file based chmode operations.  To be used by
    the initramfs code soon.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Stable-dep-of: 4624b346cf67 ("init: open /initrd.image with O_LARGEFILE")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

fs: add a vfs_fchown helper [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue Jul 14 08:47:43 2020 +0200

    fs: add a vfs_fchown helper
    
    [ Upstream commit c04011fe8cbd80af1be6e12b53193bf3846750d7 ]
    
    Add a helper for struct file based chown operations.  To be used by
    the initramfs code soon.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Stable-dep-of: 4624b346cf67 ("init: open /initrd.image with O_LARGEFILE")
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
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 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
    
    [ Upstream commit 4624b346cf67400ef46a31771011fb798dd2f999 ]
    
    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: Sasha Levin <sashal@kernel.org>

 
initramfs: switch initramfs unpacking to struct file based APIs [+ + +]
Author: Christoph Hellwig <hch@lst.de>
Date:   Tue Jul 14 08:56:19 2020 +0200

    initramfs: switch initramfs unpacking to struct file based APIs
    
    [ Upstream commit bf6419e4d5440c6d414a320506c5488857a5b001 ]
    
    There is no good reason to mess with file descriptors from in-kernel
    code, switch the initramfs unpacking to struct file based write
    instead.
    
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
    Stable-dep-of: 4624b346cf67 ("init: open /initrd.image with O_LARGEFILE")
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
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>

 
ip_gre: do not report erspan version on GRE interface [+ + +]
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Sat Dec 3 11:28:58 2022 +0800

    ip_gre: do not report erspan version on GRE interface
    
    commit ee496694b9eea651ae1aa4c4667d886cdf74aa3b upstream.
    
    Although the type I ERSPAN is based on the barebones IP + GRE
    encapsulation and no extra ERSPAN header. Report erspan version on GRE
    interface looks unreasonable. Fix this by separating the erspan and gre
    fill info.
    
    IPv6 GRE does not have this info as IPv6 only supports erspan version
    1 and 2.
    
    Reported-by: Jianlin Shi <jishi@redhat.com>
    Fixes: f989d546a2d5 ("erspan: Add type I version 0 support.")
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Acked-by: William Tu <u9012063@gmail.com>
    Link: https://lore.kernel.org/r/20221203032858.3130339-1-liuhangbin@gmail.com
    Signed-off-by: Paolo Abeni <pabeni@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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: 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: 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>

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

    Linux 5.4.274
    
    Link: https://lore.kernel.org/r/20240411095424.875421572@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: kernelci.org bot <bot@kernelci.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
loop: Call loop_config_discard() only after new config is applied [+ + +]
Author: Martijn Coenen <maco@android.com>
Date:   Thu Mar 7 12:14:05 2024 +0800

    loop: Call loop_config_discard() only after new config is applied
    
    [ Upstream commit 7c5014b0987a30e4989c90633c198aced454c0ec ]
    
    loop_set_status() calls loop_config_discard() to configure discard for
    the loop device; however, the discard configuration depends on whether
    the loop device uses encryption, and when we call it the encryption
    configuration has not been updated yet. Move the call down so we apply
    the correct discard configuration based on the new configuration.
    
    Signed-off-by: Martijn Coenen <maco@android.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Bob Liu <bob.liu@oracle.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

loop: Check for overflow while configuring loop [+ + +]
Author: Siddh Raman Pant <code@siddh.me>
Date:   Thu Mar 7 12:14:10 2024 +0800

    loop: Check for overflow while configuring loop
    
    [ Upstream commit c490a0b5a4f36da3918181a8acdc6991d967c5f3 ]
    
    The userspace can configure a loop using an ioctl call, wherein
    a configuration of type loop_config is passed (see lo_ioctl()'s
    case on line 1550 of drivers/block/loop.c). This proceeds to call
    loop_configure() which in turn calls loop_set_status_from_info()
    (see line 1050 of loop.c), passing &config->info which is of type
    loop_info64*. This function then sets the appropriate values, like
    the offset.
    
    loop_device has lo_offset of type loff_t (see line 52 of loop.c),
    which is typdef-chained to long long, whereas loop_info64 has
    lo_offset of type __u64 (see line 56 of include/uapi/linux/loop.h).
    
    The function directly copies offset from info to the device as
    follows (See line 980 of loop.c):
            lo->lo_offset = info->lo_offset;
    
    This results in an overflow, which triggers a warning in iomap_iter()
    due to a call to iomap_iter_done() which has:
            WARN_ON_ONCE(iter->iomap.offset > iter->pos);
    
    Thus, check for negative value during loop_set_status_from_info().
    
    Bug report: https://syzkaller.appspot.com/bug?id=c620fe14aac810396d3c3edc9ad73848bf69a29e
    
    Reported-and-tested-by: syzbot+a8e049cd3abd342936b6@syzkaller.appspotmail.com
    Cc: stable@vger.kernel.org
    Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Siddh Raman Pant <code@siddh.me>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20220823160810.181275-1-code@siddh.me
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

loop: Factor out configuring loop from status [+ + +]
Author: Martijn Coenen <maco@android.com>
Date:   Thu Mar 7 12:14:09 2024 +0800

    loop: Factor out configuring loop from status
    
    [ Upstream commit 0c3796c244598122a5d59d56f30d19390096817f ]
    
    Factor out this code into a separate function, so it can be reused by
    other code more easily.
    
    Signed-off-by: Martijn Coenen <maco@android.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

loop: Factor out setting loop device size [+ + +]
Author: Martijn Coenen <maco@android.com>
Date:   Thu Mar 7 12:14:07 2024 +0800

    loop: Factor out setting loop device size
    
    [ Upstream commit 5795b6f5607f7e4db62ddea144727780cb351a9b ]
    
    This code is used repeatedly.
    
    Signed-off-by: Martijn Coenen <maco@android.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

loop: loop_set_status_from_info() check before assignment [+ + +]
Author: Zhong Jinghua <zhongjinghua@huawei.com>
Date:   Thu Mar 7 12:14:11 2024 +0800

    loop: loop_set_status_from_info() check before assignment
    
    [ Upstream commit 9f6ad5d533d1c71e51bdd06a5712c4fbc8768dfa ]
    
    In loop_set_status_from_info(), lo->lo_offset and lo->lo_sizelimit should
    be checked before reassignment, because if an overflow error occurs, the
    original correct value will be changed to the wrong value, and it will not
    be changed back.
    
    More, the original patch did not solve the problem, the value was set and
    ioctl returned an error, but the subsequent io used the value in the loop
    driver, which still caused an alarm:
    
    loop_handle_cmd
     do_req_filebacked
      loff_t pos = ((loff_t) blk_rq_pos(rq) << 9) + lo->lo_offset;
      lo_rw_aio
       cmd->iocb.ki_pos = pos
    
    Fixes: c490a0b5a4f3 ("loop: Check for overflow while configuring loop")
    Signed-off-by: Zhong Jinghua <zhongjinghua@huawei.com>
    Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
    Link: https://lore.kernel.org/r/20230221095027.3656193-1-zhongjinghua@huaweicloud.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

loop: Refactor loop_set_status() size calculation [+ + +]
Author: Martijn Coenen <maco@android.com>
Date:   Thu Mar 7 12:14:08 2024 +0800

    loop: Refactor loop_set_status() size calculation
    
    [ Upstream commit b0bd158dd630bd47640e0e418c062cda1e0da5ad ]
    
    figure_loop_size() calculates the loop size based on the passed in
    parameters, but at the same time it updates the offset and sizelimit
    parameters in the loop device configuration. That is a somewhat
    unexpected side effect of a function with this name, and it is only only
    needed by one of the two callers of this function - loop_set_status().
    
    Move the lo_offset and lo_sizelimit assignment back into loop_set_status(),
    and use the newly factored out functions to validate and apply the newly
    calculated size. This allows us to get rid of figure_loop_size() in a
    follow-up commit.
    
    Signed-off-by: Martijn Coenen <maco@android.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

loop: Remove sector_t truncation checks [+ + +]
Author: Martijn Coenen <maco@android.com>
Date:   Thu Mar 7 12:14:06 2024 +0800

    loop: Remove sector_t truncation checks
    
    [ Upstream commit 083a6a50783ef54256eec3499e6575237e0e3d53 ]
    
    sector_t is now always u64, so we don't need to check for truncation.
    
    Signed-off-by: Martijn Coenen <maco@android.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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>

 
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:50:53 2024 +0800

    mm/memory-failure: fix an incorrect use of tail pages
    
    When backport commit c79c5a0a00a9 to 5.4-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: 85015a96bc24 ("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:13 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>

 
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>

 
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: 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:21: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 8 23:21:38 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: Sasha Levin <sashal@kernel.org>

netfilter: nf_tables: release batch on table validation from abort path [+ + +]
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Apr 8 23:21: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:21: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>

 
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>

 
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>

nilfs2: use a more common logging style [+ + +]
Author: Joe Perches <joe@perches.com>
Date:   Tue Aug 11 18:35:49 2020 -0700

    nilfs2: use a more common logging style
    
    [ Upstream commit a1d0747a393a079631130d61faa2a61027d1c789 ]
    
    Add macros for nilfs_<level>(sb, fmt, ...) and convert the uses of
    'nilfs_msg(sb, KERN_<LEVEL>, ...)' to 'nilfs_<level>(sb, ...)' so nilfs2
    uses a logging style more like the typical kernel logging style.
    
    Miscellanea:
    
    o Realign arguments for these uses
    
    Signed-off-by: Joe Perches <joe@perches.com>
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Link: http://lkml.kernel.org/r/1595860111-3920-4-git-send-email-konishi.ryusuke@gmail.com
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Stable-dep-of: 269cdf353b5b ("nilfs2: prevent kernel bug at submit_bh_wbc()")
    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 support for intra-function calls [+ + +]
Author: Alexandre Chartre <alexandre.chartre@oracle.com>
Date:   Tue Apr 14 12:36:12 2020 +0200

    objtool: Add support for intra-function calls
    
    commit 8aa8eb2a8f5b3305a95f39957dd2b715fa668e21 upstream.
    
    Change objtool to support intra-function calls. On x86, an intra-function
    call is represented in objtool as a push onto the stack (of the return
    address), and a jump to the destination address. That way the stack
    information is correctly updated and the call flow is still accurate.
    
    Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Miroslav Benes <mbenes@suse.cz>
    Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Link: https://lkml.kernel.org/r/20200414103618.12657-4-alexandre.chartre@oracle.com
    Signed-off-by: Rui Qi <qirui.001@bytedance.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

objtool: is_fentry_call() crashes if call has no destination [+ + +]
Author: Alexandre Chartre <alexandre.chartre@oracle.com>
Date:   Tue Apr 14 12:36:10 2020 +0200

    objtool: is_fentry_call() crashes if call has no destination
    
    commit 87cf61fe848ca8ddf091548671e168f52e8a718e upstream.
    
    Fix is_fentry_call() so that it works if a call has no destination
    set (call_dest). This needs to be done in order to support intra-
    function calls.
    
    Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Reviewed-by: Miroslav Benes <mbenes@suse.cz>
    Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Link: https://lkml.kernel.org/r/20200414103618.12657-2-alexandre.chartre@oracle.com
    Signed-off-by: Rui Qi <qirui.001@bytedance.com>
    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: Do not hardcode registers in checksum functions [+ + +]
Author: Helge Deller <deller@gmx.de>
Date:   Sun Sep 29 21:00:42 2019 +0200

    parisc: Do not hardcode registers in checksum functions
    
    [ Upstream commit 52b2d91752a82d9350981eb3b3ffc4b325c84ba9 ]
    
    Do not hardcode processor registers r19 to r22 as scratch registers.
    Instead let the compiler decide, which may give better optimization
    results when the functions get inlined.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Stable-dep-of: a2abae8f0b63 ("parisc: Fix ip_fast_csum")
    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/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: 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>

 
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>

 
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: 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>

 
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>

 
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 "loop: Check for overflow while configuring loop" [+ + +]
Author: Genjian Zhang <zhanggenjian@kylinos.cn>
Date:   Thu Mar 7 12:14:04 2024 +0800

    Revert "loop: Check for overflow while configuring loop"
    
    This reverts commit 13b2856037a651ba3ab4a8b25ecab3e791926da3.
    
    This patch lost a unlock loop_ctl_mutex in loop_get_status(...),
    which caused syzbot to report a UAF issue.The upstream patch does not
    have this issue. Therefore, we revert this patch and directly apply
    the upstream patch later on.
    
    Risk use-after-free as reported by syzbot:
    
    [   84.669496] ==================================================================
    [   84.670021] BUG: KASAN: use-after-free in __mutex_lock.isra.9+0xc13/0xcb0
    [   84.670433] Read of size 4 at addr ffff88808dba43b8 by task syz-executor.22/14230
    [   84.670885]
    [   84.670987] CPU: 1 PID: 14230 Comm: syz-executor.22 Not tainted 5.4.270 #4
    [   84.671397] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014
    [   84.671927] Call Trace:
    [   84.672085]  dump_stack+0x94/0xc7
    [   84.672293]  ? __mutex_lock.isra.9+0xc13/0xcb0
    [   84.672569]  print_address_description.constprop.6+0x16/0x220
    [   84.672915]  ? __mutex_lock.isra.9+0xc13/0xcb0
    [   84.673187]  ? __mutex_lock.isra.9+0xc13/0xcb0
    [   84.673462]  __kasan_report.cold.9+0x1a/0x32
    [   84.673723]  ? __mutex_lock.isra.9+0xc13/0xcb0
    [   84.673993]  kasan_report+0x10/0x20
    [   84.674208]  __mutex_lock.isra.9+0xc13/0xcb0
    [   84.674468]  ? __mutex_lock.isra.9+0x617/0xcb0
    [   84.674739]  ? ww_mutex_lock_interruptible+0x100/0x100
    [   84.675055]  ? ww_mutex_lock_interruptible+0x100/0x100
    [   84.675369]  ? kobject_get_unless_zero+0x144/0x190
    [   84.675668]  ? kobject_del+0x60/0x60
    [   84.675893]  ? __module_get+0x120/0x120
    [   84.676128]  ? __mutex_lock_slowpath+0x10/0x10
    [   84.676399]  mutex_lock_killable+0xde/0xf0
    [   84.676652]  ? __mutex_lock_killable_slowpath+0x10/0x10
    [   84.676967]  ? __mutex_lock_slowpath+0x10/0x10
    [   84.677243]  ? disk_block_events+0x1d/0x120
    [   84.677509]  lo_open+0x16/0xc0
    [   84.677701]  ? lo_compat_ioctl+0x160/0x160
    [   84.677954]  __blkdev_get+0xb0f/0x1160
    [   84.678185]  ? bd_may_claim+0xd0/0xd0
    [   84.678410]  ? bdev_disk_changed+0x190/0x190
    [   84.678674]  ? _raw_spin_lock+0x7c/0xd0
    [   84.678915]  ? _raw_write_lock_bh+0xd0/0xd0
    [   84.679172]  blkdev_get+0x9b/0x290
    [   84.679381]  ? ihold+0x1a/0x40
    [   84.679574]  blkdev_open+0x1bd/0x240
    [   84.679794]  do_dentry_open+0x439/0x1000
    [   84.680035]  ? blkdev_get_by_dev+0x60/0x60
    [   84.680286]  ? __x64_sys_fchdir+0x1a0/0x1a0
    [   84.680557]  ? inode_permission+0x86/0x320
    [   84.680814]  path_openat+0x998/0x4120
    [   84.681044]  ? stack_trace_consume_entry+0x160/0x160
    [   84.681348]  ? do_futex+0x136/0x1880
    [   84.681568]  ? path_mountpoint+0xb50/0xb50
    [   84.681823]  ? save_stack+0x4d/0x80
    [   84.682038]  ? save_stack+0x19/0x80
    [   84.682253]  ? __kasan_kmalloc.constprop.6+0xc1/0xd0
    [   84.682553]  ? kmem_cache_alloc+0xc7/0x210
    [   84.682804]  ? getname_flags+0xc4/0x560
    [   84.683045]  ? do_sys_open+0x1ce/0x450
    [   84.683272]  ? do_syscall_64+0x9a/0x330
    [   84.683509]  ? entry_SYSCALL_64_after_hwframe+0x5c/0xc1
    [   84.683826]  ? _raw_spin_lock+0x7c/0xd0
    [   84.684063]  ? _raw_write_lock_bh+0xd0/0xd0
    [   84.684319]  ? futex_exit_release+0x60/0x60
    [   84.684574]  ? kasan_unpoison_shadow+0x30/0x40
    [   84.684844]  ? __kasan_kmalloc.constprop.6+0xc1/0xd0
    [   84.685149]  ? get_partial_node.isra.83.part.84+0x1e5/0x340
    [   84.685485]  ? __fget_light+0x1d1/0x550
    [   84.685721]  do_filp_open+0x197/0x270
    [   84.685946]  ? may_open_dev+0xd0/0xd0
    [   84.686172]  ? kasan_unpoison_shadow+0x30/0x40
    [   84.686443]  ? __kasan_kmalloc.constprop.6+0xc1/0xd0
    [   84.686743]  ? __alloc_fd+0x1a3/0x580
    [   84.686973]  do_sys_open+0x2c7/0x450
    [   84.687195]  ? filp_open+0x60/0x60
    [   84.687406]  ? __x64_sys_timer_settime32+0x280/0x280
    [   84.687707]  do_syscall_64+0x9a/0x330
    [   84.687931]  ? syscall_return_slowpath+0x17a/0x230
    [   84.688221]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1
    [   84.688524]
    [   84.688622] Allocated by task 14056:
    [   84.688842]  save_stack+0x19/0x80
    [   84.689044]  __kasan_kmalloc.constprop.6+0xc1/0xd0
    [   84.689333]  kmem_cache_alloc_node+0xe2/0x230
    [   84.689600]  copy_process+0x165c/0x72d0
    [   84.689833]  _do_fork+0xf9/0x9a0
    [   84.690032]  __x64_sys_clone+0x17a/0x200
    [   84.690271]  do_syscall_64+0x9a/0x330
    [   84.690496]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1
    [   84.690800]
    [   84.690903] Freed by task 0:
    [   84.691081]  save_stack+0x19/0x80
    [   84.691287]  __kasan_slab_free+0x125/0x170
    [   84.691535]  kmem_cache_free+0x7a/0x2a0
    [   84.691774]  __put_task_struct+0x1ec/0x4a0
    [   84.692023]  delayed_put_task_struct+0x178/0x1d0
    [   84.692303]  rcu_core+0x538/0x16c0
    [   84.692512]  __do_softirq+0x175/0x63d
    [   84.692741]
    [   84.692840] The buggy address belongs to the object at ffff88808dba4380
    [   84.692840]  which belongs to the cache task_struct of size 3328
    [   84.693584] The buggy address is located 56 bytes inside of
    [   84.693584]  3328-byte region [ffff88808dba4380, ffff88808dba5080)
    [   84.694272] The buggy address belongs to the page:
    [   84.694563] page:ffffea000236e800 refcount:1 mapcount:0 mapping:ffff8881838acdc0 index:0x0 compound_mapcount: 0
    [   84.695166] flags: 0x100000000010200(slab|head)
    [   84.695457] raw: 0100000000010200 dead000000000100 dead000000000122 ffff8881838acdc0
    [   84.695919] raw: 0000000000000000 0000000000090009 00000001ffffffff 0000000000000000
    [   84.696375] page dumped because: kasan: bad access detected
    [   84.696705]
    [   84.696801] Memory state around the buggy address:
    [   84.697089]  ffff88808dba4280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   84.697519]  ffff88808dba4300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
    [   84.697945] >ffff88808dba4380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   84.698371]                                         ^
    [   84.698674]  ffff88808dba4400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   84.699111]  ffff88808dba4480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    [   84.699537] ==================================================================
    [   84.699965] Disabling lock debugging due to kernel taint
    
    Reported-by: k2ci <kernel-bot@kylinos.cn>
    Signed-off-by: Genjian Zhang <zhanggenjian@kylinos.cn>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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 "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: 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>

 
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>

 
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: 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>

 
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: 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>

 
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: mmal-vchiq: Allocate and free components as required [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.org>
Date:   Tue Jun 23 18:41:48 2020 +0200

    staging: mmal-vchiq: Allocate and free components as required
    
    [ Upstream commit 8c589e1794a31e9a381916b0280260ab601e4d6e ]
    
    The existing code assumed that there would only ever be 4 components,
    and never freed the entries once used.
    Allow arbitrary creation and destruction of components.
    
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
    Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
    Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Link: https://lore.kernel.org/r/20200623164235.29566-3-nsaenzjulienne@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: f37e76abd614 ("staging: vc04_services: fix information leak in create_component()")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

staging: mmal-vchiq: Fix client_component for 64 bit kernel [+ + +]
Author: Dave Stevenson <dave.stevenson@raspberrypi.org>
Date:   Mon Jun 29 17:09:02 2020 +0200

    staging: mmal-vchiq: Fix client_component for 64 bit kernel
    
    [ Upstream commit 22e64b486adc4785542f8002c3af4c895490f841 ]
    
    The MMAL client_component field is used with the event
    mechanism to allow the client to identify the component for
    which the event is generated.
    The field is only 32bits in size, therefore we can't use a
    pointer to the component in a 64 bit kernel.
    
    Component handles are already held in an array per VCHI
    instance, so use the array index as the client_component handle
    to avoid having to create a new IDR for this purpose.
    
    Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
    Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
    Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
    Link: https://lore.kernel.org/r/20200629150945.10720-5-nsaenzjulienne@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: f37e76abd614 ("staging: vc04_services: fix information leak in create_component()")
    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()
    
    [ Upstream commit ef25725b7f8aaffd7756974d3246ec44fae0a5cf ]
    
    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>
    Stable-dep-of: f37e76abd614 ("staging: vc04_services: fix information leak in create_component()")
    Signed-off-by: Sasha Levin <sashal@kernel.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()
    
    [ Upstream commit f37e76abd614b68987abc8e5c22d986013349771 ]
    
    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>
    Signed-off-by: Sasha Levin <sashal@kernel.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>

 
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>

 
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: 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: 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: 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>

 
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 memory overlapping when deleting chars in the buffer [+ + +]
Author: Yangxi Xiang <xyangxi5@gmail.com>
Date:   Tue Jun 28 17:33:22 2022 +0800

    vt: fix memory overlapping when deleting chars in the buffer
    
    commit 39cdb68c64d84e71a4a717000b6e5de208ee60cc upstream.
    
    A memory overlapping copy occurs when deleting a long line. This memory
    overlapping copy can cause data corruption when scr_memcpyw is optimized
    to memcpy because memcpy does not ensure its behavior if the destination
    buffer overlaps with the source buffer. The line buffer is not always
    broken, because the memcpy utilizes the hardware acceleration, whose
    result is not deterministic.
    
    Fix this problem by using replacing the scr_memcpyw with scr_memmovew.
    
    Fixes: 81732c3b2fed ("tty vt: Fix line garbage in virtual console on command line edition")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Yangxi Xiang <xyangxi5@gmail.com>
    Link: https://lore.kernel.org/r/20220628093322.5688-1-xyangxi5@gmail.com
    [ KN: vc_state is not a separate structure in LTS v4.19, v5.4. Adjusted the patch
      accordingly by using vc_x instead of state.x for backport. ]
    Signed-off-by: Kuntal Nayak <kuntal.nayak@broadcom.com>
    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>

 
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>

 
x86/alternative: Don't call text_poke() in lazy TLB mode [+ + +]
Author: Juergen Gross <jgross@suse.com>
Date:   Fri Oct 9 16:42:25 2020 +0200

    x86/alternative: Don't call text_poke() in lazy TLB mode
    
    commit abee7c494d8c41bb388839bccc47e06247f0d7de upstream.
    
    When running in lazy TLB mode the currently active page tables might
    be the ones of a previous process, e.g. when running a kernel thread.
    
    This can be problematic in case kernel code is being modified via
    text_poke() in a kernel thread, and on another processor exit_mmap()
    is active for the process which was running on the first cpu before
    the kernel thread.
    
    As text_poke() is using a temporary address space and the former
    address space (obtained via cpu_tlbstate.loaded_mm) is restored
    afterwards, there is a race possible in case the cpu on which
    exit_mmap() is running wants to make sure there are no stale
    references to that address space on any cpu active (this e.g. is
    required when running as a Xen PV guest, where this problem has been
    observed and analyzed).
    
    In order to avoid that, drop off TLB lazy mode before switching to the
    temporary address space.
    
    Fixes: cefa929c034eb5d ("x86/mm: Introduce temporary mm structs")
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/20201009144225.12019-1-jgross@suse.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 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/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/speculation: Support intra-function call validation [+ + +]
Author: Rui Qi <qirui.001@bytedance.com>
Date:   Wed Mar 27 17:44:47 2024 +0800

    x86/speculation: Support intra-function call validation
    
    commit 8afd1c7da2b0 ("x86/speculation: Change FILL_RETURN_BUFFER
     to work with objtool") does not support intra-function call
     stack validation, which causes kernel live patching to fail.
    This commit adds support for this, and after testing, the kernel
     live patching feature is restored to normal.
    
    Fixes: 8afd1c7da2b0 ("x86/speculation: Change FILL_RETURN_BUFFER to work with objtool")
    Cc: <stable@vger.kernel.org> # v5.4.250+
    Signed-off-by: Rui Qi <qirui.001@bytedance.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.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.4-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>