Changelog in Linux kernel 5.4.300

 
ALSA: firewire-motu: drop EPOLLOUT from poll return values as write is not supported [+ + +]
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sat Aug 30 08:37:49 2025 +0900

    ALSA: firewire-motu: drop EPOLLOUT from poll return values as write is not supported
    
    [ Upstream commit aea3493246c474bc917d124d6fb627663ab6bef0 ]
    
    The ALSA HwDep character device of the firewire-motu driver incorrectly
    returns EPOLLOUT in poll(2), even though the driver implements no operation
    for write(2). This misleads userspace applications to believe write() is
    allowed, potentially resulting in unnecessarily wakeups.
    
    This issue dates back to the driver's initial code added by a commit
    71c3797779d3 ("ALSA: firewire-motu: add hwdep interface"), and persisted
    when POLLOUT was updated to EPOLLOUT by a commit a9a08845e9ac ('vfs: do
    bulk POLL* -> EPOLL* replacement("").').
    
    This commit fixes the bug.
    
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Link: https://patch.msgid.link/20250829233749.366222-1-o-takashi@sakamocchi.jp
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: usb-audio: Add mixer quirk for Sony DualSense PS5 [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Mon May 26 17:07:48 2025 +0300

    ALSA: usb-audio: Add mixer quirk for Sony DualSense PS5
    
    [ Upstream commit 79d561c4ec0497669f19a9550cfb74812f60938b ]
    
    The Sony DualSense wireless controller (PS5) features an internal mono
    speaker, but it also provides a 3.5mm jack socket for headphone output
    and headset microphone input.
    
    Since this is a UAC1 device, it doesn't advertise any jack detection
    capability.  However, the controller is able to report HP & MIC insert
    events via HID, i.e. through a dedicated input device managed by the
    hid-playstation driver.
    
    Add a quirk to create the jack controls for headphone and headset mic,
    respectively, and setup an input handler for each of them in order to
    intercept the related hotplug events.
    
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://patch.msgid.link/20250526-dualsense-alsa-jack-v1-9-1a821463b632@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: usb-audio: Avoid multiple assignments in mixer_quirks [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Mon May 26 17:07:45 2025 +0300

    ALSA: usb-audio: Avoid multiple assignments in mixer_quirks
    
    [ Upstream commit 03ddd3bdb94df3edb1f2408b57cfb00b3d92a208 ]
    
    Handle report from checkpatch.pl:
    
      CHECK: multiple assignments should be avoided
    
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://patch.msgid.link/20250526-dualsense-alsa-jack-v1-6-1a821463b632@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: usb-audio: Convert comma to semicolon [+ + +]
Author: Chen Ni <nichen@iscas.ac.cn>
Date:   Thu Jun 12 14:02:28 2025 +0800

    ALSA: usb-audio: Convert comma to semicolon
    
    [ Upstream commit 9ca30a1b007d5fefb5752428f852a2d8d7219c1c ]
    
    Replace comma between expressions with semicolons.
    
    Using a ',' in place of a ';' can have unintended side effects.
    Although that is not the case here, it is seems best to use ';'
    unless ',' is intended.
    
    Found by inspection.
    No functional change intended.
    Compile tested only.
    
    Fixes: 79d561c4ec04 ("ALSA: usb-audio: Add mixer quirk for Sony DualSense PS5")
    Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
    Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Link: https://patch.msgid.link/20250612060228.1518028-1-nichen@iscas.ac.cn
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: usb-audio: Fix block comments in mixer_quirks [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Mon May 26 17:07:43 2025 +0300

    ALSA: usb-audio: Fix block comments in mixer_quirks
    
    [ Upstream commit 231225d8a20f8668b4fd6601d54a2fac0e0ab7a5 ]
    
    Address a couple of comment formatting issues indicated by
    checkpatch.pl:
    
      WARNING: Block comments use a trailing */ on a separate line
    
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://patch.msgid.link/20250526-dualsense-alsa-jack-v1-4-1a821463b632@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: usb-audio: Fix build with CONFIG_INPUT=n [+ + +]
Author: Takashi Iwai <tiwai@suse.de>
Date:   Fri Jun 13 10:15:30 2025 +0200

    ALSA: usb-audio: Fix build with CONFIG_INPUT=n
    
    [ Upstream commit d0630a0b80c08530857146e3bf183a7d6b743847 ]
    
    The recent addition of DualSense mixer quirk relies on the input
    device handle, and the build can fail if CONFIG_INPUT isn't set.
    Put (rather ugly) workarounds to wrap with IS_REACHABLE() for avoiding
    the build error.
    
    Fixes: 79d561c4ec04 ("ALSA: usb-audio: Add mixer quirk for Sony DualSense PS5")
    Reported-by: kernel test robot <lkp@intel.com>
    Closes: https://lore.kernel.org/oe-kbuild-all/202506130733.gnPKw2l3-lkp@intel.com/
    Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Link: https://patch.msgid.link/20250613081543.7404-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: usb-audio: Remove unneeded wmb() in mixer_quirks [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Mon May 26 17:07:47 2025 +0300

    ALSA: usb-audio: Remove unneeded wmb() in mixer_quirks
    
    [ Upstream commit 9cea7425595697802e8d55a322a251999554b8b1 ]
    
    Adding a memory barrier before wake_up() in
    snd_usb_soundblaster_remote_complete() is supposed to ensure the write
    to mixer->rc_code is visible in wait_event_interruptible() from
    snd_usb_sbrc_hwdep_read().
    
    However, this is not really necessary, since wake_up() is just a wrapper
    over __wake_up() which already executes a full memory barrier before
    accessing the state of the task to be waken up.
    
    Drop the redundant call to wmb() and implicitly fix the checkpatch
    complaint:
    
      WARNING: memory barrier without comment
    
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://patch.msgid.link/20250526-dualsense-alsa-jack-v1-8-1a821463b632@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ALSA: usb-audio: Simplify NULL comparison in mixer_quirks [+ + +]
Author: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Date:   Mon May 26 17:07:46 2025 +0300

    ALSA: usb-audio: Simplify NULL comparison in mixer_quirks
    
    [ Upstream commit f2d6d660e8fd5f4467e80743f82119201e67fa9c ]
    
    Handle report from checkpatch.pl:
    
      CHECK: Comparison to NULL could be written "t->name"
    
    Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Link: https://patch.msgid.link/20250526-dualsense-alsa-jack-v1-7-1a821463b632@collabora.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
ASoC: SOF: Intel: hda-stream: Fix incorrect variable used in error message [+ + +]
Author: Colin Ian King <colin.i.king@gmail.com>
Date:   Tue Sep 2 13:06:39 2025 +0100

    ASoC: SOF: Intel: hda-stream: Fix incorrect variable used in error message
    
    [ Upstream commit 35fc531a59694f24a2456569cf7d1a9c6436841c ]
    
    The dev_err message is reporting an error about capture streams however
    it is using the incorrect variable num_playback instead of num_capture.
    Fix this by using the correct variable num_capture.
    
    Fixes: a1d1e266b445 ("ASoC: SOF: Intel: Add Intel specific HDA stream operations")
    Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
    Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
    Link: https://patch.msgid.link/20250902120639.2626861-1-colin.i.king@gmail.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: wm8940: Correct typo in control name [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Aug 21 09:26:38 2025 +0100

    ASoC: wm8940: Correct typo in control name
    
    [ Upstream commit b4799520dcd6fe1e14495cecbbe9975d847cd482 ]
    
    Fixes: 0b5e92c5e020 ("ASoC WM8940 Driver")
    Reported-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Tested-by: Ankur Tyagi <ankur.tyagi85@gmail.com>
    Link: https://patch.msgid.link/20250821082639.1301453-3-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

ASoC: wm8974: Correct PLL rate rounding [+ + +]
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date:   Thu Aug 21 09:26:39 2025 +0100

    ASoC: wm8974: Correct PLL rate rounding
    
    [ Upstream commit 9b17d3724df55ecc2bc67978822585f2b023be48 ]
    
    Using a single value of 22500000 for both 48000Hz and 44100Hz audio
    will sometimes result in returning wrong dividers due to rounding.
    Update the code to use the actual value for both.
    
    Fixes: 51b2bb3f2568 ("ASoC: wm8974: configure pll and mclk divider automatically")
    Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
    Link: https://patch.msgid.link/20250821082639.1301453-4-ckeepax@opensource.cirrus.com
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
can: hi311x: populate ndo_change_mtu() to prevent buffer overflow [+ + +]
Author: Vincent Mailhol <mailhol@kernel.org>
Date:   Thu Sep 18 18:00:25 2025 +0900

    can: hi311x: populate ndo_change_mtu() to prevent buffer overflow
    
    [ Upstream commit ac1c7656fa717f29fac3ea073af63f0b9919ec9a ]
    
    Sending an PF_PACKET allows to bypass the CAN framework logic and to
    directly reach the xmit() function of a CAN driver. The only check
    which is performed by the PF_PACKET framework is to make sure that
    skb->len fits the interface's MTU.
    
    Unfortunately, because the sun4i_can driver does not populate its
    net_device_ops->ndo_change_mtu(), it is possible for an attacker to
    configure an invalid MTU by doing, for example:
    
      $ ip link set can0 mtu 9999
    
    After doing so, the attacker could open a PF_PACKET socket using the
    ETH_P_CANXL protocol:
    
            socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
    
    to inject a malicious CAN XL frames. For example:
    
            struct canxl_frame frame = {
                    .flags = 0xff,
                    .len = 2048,
            };
    
    The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
    check that the skb is valid, unfortunately under above conditions, the
    malicious packet is able to go through can_dev_dropped_skb() checks:
    
      1. the skb->protocol is set to ETH_P_CANXL which is valid (the
         function does not check the actual device capabilities).
    
      2. the length is a valid CAN XL length.
    
    And so, hi3110_hard_start_xmit() receives a CAN XL frame which it is
    not able to correctly handle and will thus misinterpret it as a CAN
    frame. The driver will consume frame->len as-is with no further
    checks.
    
    This can result in a buffer overflow later on in hi3110_hw_tx() on
    this line:
    
            memcpy(buf + HI3110_FIFO_EXT_DATA_OFF,
                   frame->data, frame->len);
    
    Here, frame->len corresponds to the flags field of the CAN XL frame.
    In our previous example, we set canxl_frame->flags to 0xff. Because
    the maximum expected length is 8, a buffer overflow of 247 bytes
    occurs!
    
    Populate net_device_ops->ndo_change_mtu() to ensure that the
    interface's MTU can not be set to anything bigger than CAN_MTU. By
    fixing the root cause, this prevents the buffer overflow.
    
    Fixes: 57e83fb9b746 ("can: hi311x: Add Holt HI-311x CAN driver")
    Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
    Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-2-0d1cada9393b@kernel.org
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: j1939: j1939_local_ecu_get(): undo increment when j1939_local_ecu_get() fails [+ + +]
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Sun Aug 24 19:27:40 2025 +0900

    can: j1939: j1939_local_ecu_get(): undo increment when j1939_local_ecu_get() fails
    
    [ Upstream commit 06e02da29f6f1a45fc07bd60c7eaf172dc21e334 ]
    
    Since j1939_sk_bind() and j1939_sk_release() call j1939_local_ecu_put()
    when J1939_SOCK_BOUND was already set, but the error handling path for
    j1939_sk_bind() will not set J1939_SOCK_BOUND when j1939_local_ecu_get()
    fails, j1939_local_ecu_get() needs to undo priv->ents[sa].nusers++ when
    j1939_local_ecu_get() returns an error.
    
    Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol")
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Tested-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://patch.msgid.link/e7f80046-4ff7-4ce2-8ad8-7c3c678a42c9@I-love.SAKURA.ne.jp
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: j1939: j1939_sk_bind(): call j1939_priv_put() immediately when j1939_local_ecu_get() failed [+ + +]
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date:   Sun Aug 24 19:30:09 2025 +0900

    can: j1939: j1939_sk_bind(): call j1939_priv_put() immediately when j1939_local_ecu_get() failed
    
    [ Upstream commit f214744c8a27c3c1da6b538c232da22cd027530e ]
    
    Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct
    callback") expects that a call to j1939_priv_put() can be unconditionally
    delayed until j1939_sk_sock_destruct() is called. But a refcount leak will
    happen when j1939_sk_bind() is called again after j1939_local_ecu_get()
     from previous j1939_sk_bind() call returned an error. We need to call
    j1939_priv_put() before j1939_sk_bind() returns an error.
    
    Fixes: 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct callback")
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Tested-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
    Link: https://patch.msgid.link/4f49a1bc-a528-42ad-86c0-187268ab6535@I-love.SAKURA.ne.jp
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow [+ + +]
Author: Vincent Mailhol <mailhol@kernel.org>
Date:   Thu Sep 18 18:00:27 2025 +0900

    can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow
    
    [ Upstream commit 17c8d794527f01def0d1c8b7dc2d7b8d34fed0e6 ]
    
    Sending an PF_PACKET allows to bypass the CAN framework logic and to
    directly reach the xmit() function of a CAN driver. The only check
    which is performed by the PF_PACKET framework is to make sure that
    skb->len fits the interface's MTU.
    
    Unfortunately, because the mcba_usb driver does not populate its
    net_device_ops->ndo_change_mtu(), it is possible for an attacker to
    configure an invalid MTU by doing, for example:
    
      $ ip link set can0 mtu 9999
    
    After doing so, the attacker could open a PF_PACKET socket using the
    ETH_P_CANXL protocol:
    
            socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
    
    to inject a malicious CAN XL frames. For example:
    
            struct canxl_frame frame = {
                    .flags = 0xff,
                    .len = 2048,
            };
    
    The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
    check that the skb is valid, unfortunately under above conditions, the
    malicious packet is able to go through can_dev_dropped_skb() checks:
    
      1. the skb->protocol is set to ETH_P_CANXL which is valid (the
         function does not check the actual device capabilities).
    
      2. the length is a valid CAN XL length.
    
    And so, mcba_usb_start_xmit() receives a CAN XL frame which it is not
    able to correctly handle and will thus misinterpret it as a CAN frame.
    
    This can result in a buffer overflow. The driver will consume cf->len
    as-is with no further checks on these lines:
    
            usb_msg.dlc = cf->len;
    
            memcpy(usb_msg.data, cf->data, usb_msg.dlc);
    
    Here, cf->len corresponds to the flags field of the CAN XL frame. In
    our previous example, we set canxl_frame->flags to 0xff. Because the
    maximum expected length is 8, a buffer overflow of 247 bytes occurs!
    
    Populate net_device_ops->ndo_change_mtu() to ensure that the
    interface's MTU can not be set to anything bigger than CAN_MTU. By
    fixing the root cause, this prevents the buffer overflow.
    
    Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer")
    Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
    Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-4-0d1cada9393b@kernel.org
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: peak_usb: fix shift-out-of-bounds issue [+ + +]
Author: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
Date:   Thu Sep 18 15:23:57 2025 +0200

    can: peak_usb: fix shift-out-of-bounds issue
    
    [ Upstream commit c443be70aaee42c2d1d251e0329e0a69dd96ae54 ]
    
    Explicitly uses a 64-bit constant when the number of bits used for its
    shifting is 32 (which is the case for PC CAN FD interfaces supported by
    this driver).
    
    Signed-off-by: Stéphane Grosjean <stephane.grosjean@hms-networks.com>
    Link: https://patch.msgid.link/20250918132413.30071-1-stephane.grosjean@free.fr
    Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Closes: https://lore.kernel.org/20250917-aboriginal-refined-honeybee-82b1aa-mkl@pengutronix.de
    Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
    [mkl: update subject, apply manually]
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: rcar_can: rcar_can_resume(): fix s2ram with PSCI [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Aug 14 13:26:37 2025 +0200

    can: rcar_can: rcar_can_resume(): fix s2ram with PSCI
    
    [ Upstream commit 5c793afa07da6d2d4595f6c73a2a543a471bb055 ]
    
    On R-Car Gen3 using PSCI, s2ram powers down the SoC.  After resume, the
    CAN interface no longer works, until it is brought down and up again.
    
    Fix this by calling rcar_can_start() from the PM resume callback, to
    fully initialize the controller instead of just restarting it.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Link: https://patch.msgid.link/699b2f7fcb60b31b6f976a37f08ce99c5ffccb31.1755165227.git.geert+renesas@glider.be
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow [+ + +]
Author: Vincent Mailhol <mailhol@kernel.org>
Date:   Thu Sep 18 18:00:26 2025 +0900

    can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow
    
    [ Upstream commit 61da0bd4102c459823fbe6b8b43b01fb6ace4a22 ]
    
    Sending an PF_PACKET allows to bypass the CAN framework logic and to
    directly reach the xmit() function of a CAN driver. The only check
    which is performed by the PF_PACKET framework is to make sure that
    skb->len fits the interface's MTU.
    
    Unfortunately, because the sun4i_can driver does not populate its
    net_device_ops->ndo_change_mtu(), it is possible for an attacker to
    configure an invalid MTU by doing, for example:
    
      $ ip link set can0 mtu 9999
    
    After doing so, the attacker could open a PF_PACKET socket using the
    ETH_P_CANXL protocol:
    
            socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))
    
    to inject a malicious CAN XL frames. For example:
    
            struct canxl_frame frame = {
                    .flags = 0xff,
                    .len = 2048,
            };
    
    The CAN drivers' xmit() function are calling can_dev_dropped_skb() to
    check that the skb is valid, unfortunately under above conditions, the
    malicious packet is able to go through can_dev_dropped_skb() checks:
    
      1. the skb->protocol is set to ETH_P_CANXL which is valid (the
         function does not check the actual device capabilities).
    
      2. the length is a valid CAN XL length.
    
    And so, sun4ican_start_xmit() receives a CAN XL frame which it is not
    able to correctly handle and will thus misinterpret it as a CAN frame.
    
    This can result in a buffer overflow. The driver will consume cf->len
    as-is with no further checks on this line:
    
            dlc = cf->len;
    
    Here, cf->len corresponds to the flags field of the CAN XL frame. In
    our previous example, we set canxl_frame->flags to 0xff. Because the
    maximum expected length is 8, a buffer overflow of 247 bytes occurs a
    couple line below when doing:
    
            for (i = 0; i < dlc; i++)
                    writel(cf->data[i], priv->base + (dreg + i * 4));
    
    Populate net_device_ops->ndo_change_mtu() to ensure that the
    interface's MTU can not be set to anything bigger than CAN_MTU. By
    fixing the root cause, this prevents the buffer overflow.
    
    Fixes: 0738eff14d81 ("can: Allwinner A10/A20 CAN Controller support - Kernel module")
    Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
    Link: https://patch.msgid.link/20250918-can-fix-mtu-v1-3-0d1cada9393b@kernel.org
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cgroup: split cgroup_destroy_wq into 3 workqueues [+ + +]
Author: Chen Ridong <chenridong@huawei.com>
Date:   Tue Aug 19 01:07:24 2025 +0000

    cgroup: split cgroup_destroy_wq into 3 workqueues
    
    [ Upstream commit 79f919a89c9d06816dbdbbd168fa41d27411a7f9 ]
    
    A hung task can occur during [1] LTP cgroup testing when repeatedly
    mounting/unmounting perf_event and net_prio controllers with
    systemd.unified_cgroup_hierarchy=1. The hang manifests in
    cgroup_lock_and_drain_offline() during root destruction.
    
    Related case:
    cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event
    cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio
    
    Call Trace:
            cgroup_lock_and_drain_offline+0x14c/0x1e8
            cgroup_destroy_root+0x3c/0x2c0
            css_free_rwork_fn+0x248/0x338
            process_one_work+0x16c/0x3b8
            worker_thread+0x22c/0x3b0
            kthread+0xec/0x100
            ret_from_fork+0x10/0x20
    
    Root Cause:
    
    CPU0                            CPU1
    mount perf_event                umount net_prio
    cgroup1_get_tree                cgroup_kill_sb
    rebind_subsystems               // root destruction enqueues
                                    // cgroup_destroy_wq
    // kill all perf_event css
                                    // one perf_event css A is dying
                                    // css A offline enqueues cgroup_destroy_wq
                                    // root destruction will be executed first
                                    css_free_rwork_fn
                                    cgroup_destroy_root
                                    cgroup_lock_and_drain_offline
                                    // some perf descendants are dying
                                    // cgroup_destroy_wq max_active = 1
                                    // waiting for css A to die
    
    Problem scenario:
    1. CPU0 mounts perf_event (rebind_subsystems)
    2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work
    3. A dying perf_event CSS gets queued for offline after root destruction
    4. Root destruction waits for offline completion, but offline work is
       blocked behind root destruction in cgroup_destroy_wq (max_active=1)
    
    Solution:
    Split cgroup_destroy_wq into three dedicated workqueues:
    cgroup_offline_wq – Handles CSS offline operations
    cgroup_release_wq – Manages resource release
    cgroup_free_wq – Performs final memory deallocation
    
    This separation eliminates blocking in the CSS free path while waiting for
    offline operations to complete.
    
    [1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers
    Fixes: 334c3679ec4b ("cgroup: reimplement rebind_subsystems() using cgroup_apply_control() and friends")
    Reported-by: Gao Yingjie <gaoyingjie@uniontech.com>
    Signed-off-by: Chen Ridong <chenridong@huawei.com>
    Suggested-by: Teju Heo <tj@kernel.org>
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
cnic: Fix use-after-free bugs in cnic_delete_task [+ + +]
Author: Duoming Zhou <duoming@zju.edu.cn>
Date:   Wed Sep 17 13:46:02 2025 +0800

    cnic: Fix use-after-free bugs in cnic_delete_task
    
    [ Upstream commit cfa7d9b1e3a8604afc84e9e51d789c29574fb216 ]
    
    The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),
    which does not guarantee that the delayed work item 'delete_task' has
    fully completed if it was already running. Additionally, the delayed work
    item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only
    blocks and waits for work items that were already queued to the
    workqueue prior to its invocation. Any work items submitted after
    flush_workqueue() is called are not included in the set of tasks that the
    flush operation awaits. This means that after the cyclic work items have
    finished executing, a delayed work item may still exist in the workqueue.
    This leads to use-after-free scenarios where the cnic_dev is deallocated
    by cnic_free_dev(), while delete_task remains active and attempt to
    dereference cnic_dev in cnic_delete_task().
    
    A typical race condition is illustrated below:
    
    CPU 0 (cleanup)              | CPU 1 (delayed work callback)
    cnic_netdev_event()          |
      cnic_stop_hw()             | cnic_delete_task()
        cnic_cm_stop_bnx2x_hw()  | ...
          cancel_delayed_work()  | /* the queue_delayed_work()
          flush_workqueue()      |    executes after flush_workqueue()*/
                                 | queue_delayed_work()
      cnic_free_dev(dev)//free   | cnic_delete_task() //new instance
                                 |   dev = cp->dev; //use
    
    Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
    that the cyclic delayed work item is properly canceled and that any
    ongoing execution of the work item completes before the cnic_dev is
    deallocated. Furthermore, since cancel_delayed_work_sync() uses
    __flush_work(work, true) to synchronously wait for any currently
    executing instance of the work item to finish, the flush_workqueue()
    becomes redundant and should be removed.
    
    This bug was identified through static analysis. To reproduce the issue
    and validate the fix, I simulated the cnic PCI device in QEMU and
    introduced intentional delays — such as inserting calls to ssleep()
    within the cnic_delete_task() function — to increase the likelihood
    of triggering the bug.
    
    Fixes: fdf24086f475 ("cnic: Defer iscsi connection cleanup")
    Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees [+ + +]
Author: Stephan Gerhold <stephan.gerhold@linaro.org>
Date:   Wed Feb 12 18:03:54 2025 +0100

    dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees
    
    commit 5068b5254812433e841a40886e695633148d362d upstream.
    
    When we don't have a clock specified in the device tree, we have no way to
    ensure the BAM is on. This is often the case for remotely-controlled or
    remotely-powered BAM instances. In this case, we need to read num-channels
    from the DT to have all the necessary information to complete probing.
    
    However, at the moment invalid device trees without clock and without
    num-channels still continue probing, because the error handling is missing
    return statements. The driver will then later try to read the number of
    channels from the registers. This is unsafe, because it relies on boot
    firmware and lucky timing to succeed. Unfortunately, the lack of proper
    error handling here has been abused for several Qualcomm SoCs upstream,
    causing early boot crashes in several situations [1, 2].
    
    Avoid these early crashes by erroring out when any of the required DT
    properties are missing. Note that this will break some of the existing DTs
    upstream (mainly BAM instances related to the crypto engine). However,
    clearly these DTs have never been tested properly, since the error in the
    kernel log was just ignored. It's safer to disable the crypto engine for
    these broken DTBs.
    
    [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/
    [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/
    
    Cc: stable@vger.kernel.org
    Fixes: 48d163b1aa6e ("dmaengine: qcom: bam_dma: get num-channels and num-ees from dt")
    Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
    Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
    Link: https://lore.kernel.org/r/20250212-bam-dma-fixes-v1-8-f560889e65d8@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dmaengine: ti: edma: Fix memory allocation size for queue_priority_map [+ + +]
Author: Anders Roxell <anders.roxell@linaro.org>
Date:   Sat Aug 30 11:49:53 2025 +0200

    dmaengine: ti: edma: Fix memory allocation size for queue_priority_map
    
    [ Upstream commit e63419dbf2ceb083c1651852209c7f048089ac0f ]
    
    Fix a critical memory allocation bug in edma_setup_from_hw() where
    queue_priority_map was allocated with insufficient memory. The code
    declared queue_priority_map as s8 (*)[2] (pointer to array of 2 s8),
    but allocated memory using sizeof(s8) instead of the correct size.
    
    This caused out-of-bounds memory writes when accessing:
      queue_priority_map[i][0] = i;
      queue_priority_map[i][1] = i;
    
    The bug manifested as kernel crashes with "Oops - undefined instruction"
    on ARM platforms (BeagleBoard-X15) during EDMA driver probe, as the
    memory corruption triggered kernel hardening features on Clang.
    
    Change the allocation to use sizeof(*queue_priority_map) which
    automatically gets the correct size for the 2D array structure.
    
    Fixes: 2b6b3b742019 ("ARM/dmaengine: edma: Merge the two drivers under drivers/dma/")
    Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
    Link: https://lore.kernel.org/r/20250830094953.3038012-1-anders.roxell@linaro.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
drm/gma500: Fix null dereference in hdmi teardown [+ + +]
Author: Zabelin Nikita <n.zabelin@mt-integration.ru>
Date:   Thu Sep 18 18:06:59 2025 +0300

    drm/gma500: Fix null dereference in hdmi teardown
    
    [ Upstream commit 352e66900cde63f3dadb142364d3c35170bbaaff ]
    
    pci_set_drvdata sets the value of pdev->driver_data to NULL,
    after which the driver_data obtained from the same dev is
    dereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev is
    extracted from it. To prevent this, swap these calls.
    
    Found by Linux Verification Center (linuxtesting.org) with Svacer.
    
    Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support")
    Signed-off-by: Zabelin Nikita <n.zabelin@mt-integration.ru>
    Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    Link: https://lore.kernel.org/r/20250918150703.2562604-1-n.zabelin@mt-integration.ru
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
EDAC/altera: Delete an inappropriate dma_free_coherent() call [+ + +]
Author: Salah Triki <salah.triki@gmail.com>
Date:   Thu Jul 31 04:15:27 2025 +0100

    EDAC/altera: Delete an inappropriate dma_free_coherent() call
    
    commit ff2a66d21fd2364ed9396d151115eec59612b200 upstream.
    
    dma_free_coherent() must only be called if the corresponding
    dma_alloc_coherent() call has succeeded. Calling it when the allocation fails
    leads to undefined behavior.
    
    Delete the wrong call.
    
      [ bp: Massage commit message. ]
    
    Fixes: 71bcada88b0f3 ("edac: altera: Add Altera SDRAM EDAC support")
    Signed-off-by: Salah Triki <salah.triki@gmail.com>
    Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
    Acked-by: Dinh Nguyen <dinguyen@kernel.org>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/aIrfzzqh4IzYtDVC@pc
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fbcon: fix integer overflow in fbcon_do_set_font [+ + +]
Author: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
Date:   Fri Sep 12 10:00:23 2025 -0700

    fbcon: fix integer overflow in fbcon_do_set_font
    
    commit 1a194e6c8e1ee745e914b0b7f50fa86c89ed13fe upstream.
    
    Fix integer overflow vulnerabilities in fbcon_do_set_font() where font
    size calculations could overflow when handling user-controlled font
    parameters.
    
    The vulnerabilities occur when:
    1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount
       multiplication with user-controlled values that can overflow.
    2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow
    3. This results in smaller allocations than expected, leading to buffer
       overflows during font data copying.
    
    Add explicit overflow checking using check_mul_overflow() and
    check_add_overflow() kernel helpers to safety validate all size
    calculations before allocation.
    
    Signed-off-by: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
    Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
    Fixes: 39b3cffb8cf3 ("fbcon: prevent user font height or width change from causing potential out-of-bounds access")
    Cc: George Kennedy <george.kennedy@oracle.com>
    Cc: stable <stable@vger.kernel.org>
    Cc: syzbot+38a3699c7eaf165b97a6@syzkaller.appspotmail.com
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Simona Vetter <simona@ffwll.ch>
    Cc: Helge Deller <deller@gmx.de>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Cc: Qianqiang Liu <qianqiang.liu@163.com>
    Cc: Shixiong Ou <oushixiong@kylinos.cn>
    Cc: Kees Cook <kees@kernel.org>
    Cc: <stable@vger.kernel.org> # v5.9+
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Link: https://lore.kernel.org/r/20250912170023.3931881-1-samasth.norway.ananda@oracle.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fbcon: Fix OOB access in font allocation [+ + +]
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date:   Mon Sep 22 15:45:54 2025 +0200

    fbcon: Fix OOB access in font allocation
    
    commit 9b2f5ef00e852f8e8902a4d4f73aeedc60220c12 upstream.
    
    Commit 1a194e6c8e1e ("fbcon: fix integer overflow in fbcon_do_set_font")
    introduced an out-of-bounds access by storing data and allocation sizes
    in the same variable. Restore the old size calculation and use the new
    variable 'alloc_size' for the allocation.
    
    Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
    Fixes: 1a194e6c8e1e ("fbcon: fix integer overflow in fbcon_do_set_font")
    Reported-by: Jani Nikula <jani.nikula@linux.intel.com>
    Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15020
    Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6201
    Cc: Samasth Norway Ananda <samasth.norway.ananda@oracle.com>
    Cc: Thomas Zimmermann <tzimmermann@suse.de>
    Cc: George Kennedy <george.kennedy@oracle.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Simona Vetter <simona@ffwll.ch>
    Cc: Helge Deller <deller@gmx.de>
    Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
    Cc: Sam Ravnborg <sam@ravnborg.org>
    Cc: Qianqiang Liu <qianqiang.liu@163.com>
    Cc: Shixiong Ou <oushixiong@kylinos.cn>
    Cc: Kees Cook <kees@kernel.org>
    Cc: <stable@vger.kernel.org> # v5.9+
    Cc: Zsolt Kajtar <soci@c64.rulez.org>
    Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
    Reviewed-by: Qianqiang Liu <qianqiang.liu@163.com>
    Link: https://lore.kernel.org/r/20250922134619.257684-1-tzimmermann@suse.de
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
fuse: check if copy_file_range() returns larger than requested size [+ + +]
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Aug 12 14:07:54 2025 +0200

    fuse: check if copy_file_range() returns larger than requested size
    
    commit e5203209b3935041dac541bc5b37efb44220cc0b upstream.
    
    Just like write(), copy_file_range() should check if the return value is
    less or equal to the requested number of bytes.
    
    Reported-by: Chunsheng Luo <luochunsheng@ustc.edu>
    Closes: https://lore.kernel.org/all/20250807062425.694-1-luochunsheng@ustc.edu/
    Fixes: 88bc7d5097a1 ("fuse: add support for copy_file_range()")
    Cc: <stable@vger.kernel.org> # v4.20
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

fuse: prevent overflow in copy_file_range return value [+ + +]
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Tue Aug 12 14:46:34 2025 +0200

    fuse: prevent overflow in copy_file_range return value
    
    commit 1e08938c3694f707bb165535df352ac97a8c75c9 upstream.
    
    The FUSE protocol uses struct fuse_write_out to convey the return value of
    copy_file_range, which is restricted to uint32_t.  But the COPY_FILE_RANGE
    interface supports a 64-bit size copies.
    
    Currently the number of bytes copied is silently truncated to 32-bit, which
    may result in poor performance or even failure to copy in case of
    truncation to zero.
    
    Reported-by: Florian Weimer <fweimer@redhat.com>
    Closes: https://lore.kernel.org/all/lhuh5ynl8z5.fsf@oldenburg.str.redhat.com/
    Fixes: 88bc7d5097a1 ("fuse: add support for copy_file_range()")
    Cc: <stable@vger.kernel.org> # v4.20
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
genirq/affinity: Add irq_update_affinity_desc() [+ + +]
Author: John Garry <john.g.garry@oracle.com>
Date:   Wed Dec 2 18:36:53 2020 +0800

    genirq/affinity: Add irq_update_affinity_desc()
    
    [ Upstream commit 1d3aec89286254487df7641c30f1b14ad1d127a5 ]
    
    Add a function to allow the affinity of an interrupt be switched to
    managed, such that interrupts allocated for platform devices may be
    managed.
    
    This new interface has certain limitations, and attempts to use it in the
    following circumstances will fail:
    - For when the kernel is configured for generic IRQ reservation mode (in
      config GENERIC_IRQ_RESERVATION_MODE). The reason being that it could
      conflict with managed vs. non-managed interrupt accounting.
    - The interrupt is already started, which should not be the case during
      init
    - The interrupt is already configured as managed, which means double init
    
    Suggested-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: John Garry <john.garry@huawei.com>
    Signed-off-by: Marc Zyngier <maz@kernel.org>
    Link: https://lore.kernel.org/r/1606905417-183214-2-git-send-email-john.garry@huawei.com
    Stable-dep-of: 915470e1b44e ("i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
genirq: Export affinity setter for modules [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue May 18 11:17:26 2021 +0200

    genirq: Export affinity setter for modules
    
    [ Upstream commit 4d80d6ca5d77fde9880da8466e5b64f250e5bf82 ]
    
    Perf modules abuse irq_set_affinity_hint() to set the affinity of system
    PMU interrupts just because irq_set_affinity() was not exported.
    
    The fact that irq_set_affinity_hint() actually sets the affinity is a
    non-documented side effect and the name is clearly saying it's a hint.
    
    To clean this up, export the real affinity setter.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Mark Rutland <mark.rutland@arm.com>
    Link: https://lore.kernel.org/r/20210518093117.968251441@linutronix.de
    Stable-dep-of: 915470e1b44e ("i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

genirq: Provide new interfaces for affinity hints [+ + +]
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Sep 3 11:24:17 2021 -0400

    genirq: Provide new interfaces for affinity hints
    
    [ Upstream commit 65c7cdedeb3026fabcc967a7aae2f755ad4d0783 ]
    
    The discussion about removing the side effect of irq_set_affinity_hint() of
    actually applying the cpumask (if not NULL) as affinity to the interrupt,
    unearthed a few unpleasantries:
    
      1) The modular perf drivers rely on the current behaviour for the very
         wrong reasons.
    
      2) While none of the other drivers prevents user space from changing
         the affinity, a cursorily inspection shows that there are at least
         expectations in some drivers.
    
    #1 needs to be cleaned up anyway, so that's not a problem
    
    #2 might result in subtle regressions especially when irqbalanced (which
       nowadays ignores the affinity hint) is disabled.
    
    Provide new interfaces:
    
      irq_update_affinity_hint()  - Only sets the affinity hint pointer
      irq_set_affinity_and_hint() - Set the pointer and apply the affinity to
                                    the interrupt
    
    Make irq_set_affinity_hint() a wrapper around irq_apply_affinity_hint() and
    document it to be phased out.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Ming Lei <ming.lei@redhat.com>
    Link: https://lore.kernel.org/r/20210501021832.743094-1-jesse.brandeburg@intel.com
    Link: https://lore.kernel.org/r/20210903152430.244937-2-nitesh@redhat.com
    Stable-dep-of: 915470e1b44e ("i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
i40e: add mask to apply valid bits for itr_idx [+ + +]
Author: Lukasz Czapnik <lukasz.czapnik@intel.com>
Date:   Mon Sep 29 12:02:25 2025 -0400

    i40e: add mask to apply valid bits for itr_idx
    
    [ Upstream commit eac04428abe9f9cb203ffae4600791ea1d24eb18 ]
    
    The ITR index (itr_idx) is only 2 bits wide. When constructing the
    register value for QINT_RQCTL, all fields are ORed together. Without
    masking, higher bits from itr_idx may overwrite adjacent fields in the
    register.
    
    Apply I40E_QINT_RQCTL_ITR_INDX_MASK to ensure only the intended bits are
    set.
    
    Fixes: 5c3c48ac6bf5 ("i40e: implement virtual device interface")
    Cc: stable@vger.kernel.org
    Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    [ Added missing linux/bitfield.h header for FIELD_PREP macro ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: add max boundary check for VF filters [+ + +]
Author: Lukasz Czapnik <lukasz.czapnik@intel.com>
Date:   Wed Aug 13 12:45:16 2025 +0200

    i40e: add max boundary check for VF filters
    
    commit cb79fa7118c150c3c76a327894bb2eb878c02619 upstream.
    
    There is no check for max filters that VF can request. Add it.
    
    Fixes: e284fc280473 ("i40e: Add and delete cloud filter")
    Cc: stable@vger.kernel.org
    Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: add validation for ring_len param [+ + +]
Author: Lukasz Czapnik <lukasz.czapnik@intel.com>
Date:   Mon Sep 29 10:53:52 2025 -0400

    i40e: add validation for ring_len param
    
    [ Upstream commit 55d225670def06b01af2e7a5e0446fbe946289e8 ]
    
    The `ring_len` parameter provided by the virtual function (VF)
    is assigned directly to the hardware memory context (HMC) without
    any validation.
    
    To address this, introduce an upper boundary check for both Tx and Rx
    queue lengths. The maximum number of descriptors supported by the
    hardware is 8k-32.
    Additionally, enforce alignment constraints: Tx rings must be a multiple
    of 8, and Rx rings must be a multiple of 32.
    
    Fixes: 5c3c48ac6bf5 ("i40e: implement virtual device interface")
    Cc: stable@vger.kernel.org
    Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: fix idx validation in config queues msg [+ + +]
Author: Lukasz Czapnik <lukasz.czapnik@intel.com>
Date:   Mon Sep 29 10:58:37 2025 -0400

    i40e: fix idx validation in config queues msg
    
    [ Upstream commit f1ad24c5abe1eaef69158bac1405a74b3c365115 ]
    
    Ensure idx is within range of active/initialized TCs when iterating over
    vf->ch[idx] in i40e_vc_config_queues_msg().
    
    Fixes: c27eac48160d ("i40e: Enable ADq and create queue channel/s on VF")
    Cc: stable@vger.kernel.org
    Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Kamakshi Nellore <nellorex.kamakshi@intel.com> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    [ Adjust context ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: fix idx validation in i40e_validate_queue_map [+ + +]
Author: Lukasz Czapnik <lukasz.czapnik@intel.com>
Date:   Wed Aug 13 12:45:12 2025 +0200

    i40e: fix idx validation in i40e_validate_queue_map
    
    commit aa68d3c3ac8d1dcec40d52ae27e39f6d32207009 upstream.
    
    Ensure idx is within range of active/initialized TCs when iterating over
    vf->ch[idx] in i40e_validate_queue_map().
    
    Fixes: c27eac48160d ("i40e: Enable ADq and create queue channel/s on VF")
    Cc: stable@vger.kernel.org
    Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Kamakshi Nellore <nellorex.kamakshi@intel.com> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: fix input validation logic for action_meta [+ + +]
Author: Lukasz Czapnik <lukasz.czapnik@intel.com>
Date:   Wed Aug 13 12:45:14 2025 +0200

    i40e: fix input validation logic for action_meta
    
    commit 9739d5830497812b0bdeaee356ddefbe60830b88 upstream.
    
    Fix condition to check 'greater or equal' to prevent OOB dereference.
    
    Fixes: e284fc280473 ("i40e: Add and delete cloud filter")
    Cc: stable@vger.kernel.org
    Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path [+ + +]
Author: Michal Schmidt <mschmidt@redhat.com>
Date:   Mon Aug 18 17:39:03 2025 +0200

    i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path
    
    [ Upstream commit 915470e1b44e71d1dd07ee067276f003c3521ee3 ]
    
    If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration
    later than the first, the error path wants to free the IRQs requested
    so far. However, it uses the wrong dev_id argument for free_irq(), so
    it does not free the IRQs correctly and instead triggers the warning:
    
     Trying to free already-free IRQ 173
     WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0
     Modules linked in: i40e(+) [...]
     CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)
     Hardware name: [...]
     RIP: 0010:__free_irq+0x192/0x2c0
     [...]
     Call Trace:
      <TASK>
      free_irq+0x32/0x70
      i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]
      i40e_vsi_request_irq+0x79/0x80 [i40e]
      i40e_vsi_open+0x21f/0x2f0 [i40e]
      i40e_open+0x63/0x130 [i40e]
      __dev_open+0xfc/0x210
      __dev_change_flags+0x1fc/0x240
      netif_change_flags+0x27/0x70
      do_setlink.isra.0+0x341/0xc70
      rtnl_newlink+0x468/0x860
      rtnetlink_rcv_msg+0x375/0x450
      netlink_rcv_skb+0x5c/0x110
      netlink_unicast+0x288/0x3c0
      netlink_sendmsg+0x20d/0x430
      ____sys_sendmsg+0x3a2/0x3d0
      ___sys_sendmsg+0x99/0xe0
      __sys_sendmsg+0x8a/0xf0
      do_syscall_64+0x82/0x2c0
      entry_SYSCALL_64_after_hwframe+0x76/0x7e
      [...]
      </TASK>
     ---[ end trace 0000000000000000 ]---
    
    Use the same dev_id for free_irq() as for request_irq().
    
    I tested this with inserting code to fail intentionally.
    
    Fixes: 493fb30011b3 ("i40e: Move q_vectors from pointer to array to array of pointers")
    Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
    Tested-by: Rinitha S <sx.rinitha@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>

i40e: fix validation of VF state in get resources [+ + +]
Author: Lukasz Czapnik <lukasz.czapnik@intel.com>
Date:   Mon Sep 29 11:02:01 2025 -0400

    i40e: fix validation of VF state in get resources
    
    [ Upstream commit 877b7e6ffc23766448236e8732254534c518ba42 ]
    
    VF state I40E_VF_STATE_ACTIVE is not the only state in which
    VF is actually active so it should not be used to determine
    if a VF is allowed to obtain resources.
    
    Use I40E_VF_STATE_RESOURCES_LOADED that is set only in
    i40e_vc_get_vf_resources_msg() and cleared during reset.
    
    Fixes: 61125b8be85d ("i40e: Fix failed opcode appearing if handling messages from VF")
    Cc: stable@vger.kernel.org
    Signed-off-by: Lukasz Czapnik <lukasz.czapnik@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Signed-off-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
    Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
    [ Adjust context ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: increase max descriptors for XL710 [+ + +]
Author: Justin Bronder <jsbronder@cold-front.org>
Date:   Mon Sep 29 10:53:51 2025 -0400

    i40e: increase max descriptors for XL710
    
    [ Upstream commit aa6908ca3bd1e713fd6cd8d7193a008f060bf7d9 ]
    
    In Tables 8-12 and 8-22 in the X710/XXV710/XL710 datasheet, the QLEN
    description states that the maximum size of the descriptor queue is 8k
    minus 32, or 8160.
    
    Signed-off-by: Justin Bronder <jsbronder@cold-front.org>
    Reviewed-by: Jacob Keller <jacob.e.keller@intel.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>
    Link: https://lore.kernel.org/r/20231113231047.548659-2-anthony.l.nguyen@intel.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Stable-dep-of: 55d225670def ("i40e: add validation for ring_len param")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

i40e: remove redundant memory barrier when cleaning Tx descs [+ + +]
Author: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Date:   Fri Aug 22 17:16:17 2025 +0200

    i40e: remove redundant memory barrier when cleaning Tx descs
    
    [ Upstream commit e37084a26070c546ae7961ee135bbfb15fbe13fd ]
    
    i40e has a feature which writes to memory location last descriptor
    successfully sent. Memory barrier in i40e_clean_tx_irq() was used to
    avoid forward-reading descriptor fields in case DD bit was not set.
    Having mentioned feature in place implies that such situation will not
    happen as we know in advance how many descriptors HW has dealt with.
    
    Besides, this barrier placement was wrong. Idea is to have this
    protection *after* reading DD bit from HW descriptor, not before.
    Digging through git history showed me that indeed barrier was before DD
    bit check, anyways the commit introducing i40e_get_head() should have
    wiped it out altogether.
    
    Also, there was one commit doing s/read_barrier_depends/smp_rmb when get
    head feature was already in place, but it was only theoretical based on
    ixgbe experiences, which is different in these terms as that driver has
    to read DD bit from HW descriptor.
    
    Fixes: 1943d8ba9507 ("i40e/i40evf: enable hardware feature head write back")
    Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
    Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
    Tested-by: Rinitha S <sx.rinitha@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>

i40e: Use irq_update_affinity_hint() [+ + +]
Author: Nitesh Narayan Lal <nitesh@redhat.com>
Date:   Fri Sep 3 11:24:19 2021 -0400

    i40e: Use irq_update_affinity_hint()
    
    [ Upstream commit d34c54d1739c2cdf2e4437b74e6da269147f4987 ]
    
    The driver uses irq_set_affinity_hint() for two purposes:
    
     - To set the affinity_hint which is consumed by the userspace for
       distributing the interrupts
    
     - To apply an affinity that it provides for the i40e interrupts
    
    The latter is done to ensure that all the interrupts are evenly spread
    across all available CPUs. However, since commit a0c9259dc4e1 ("irq/matrix:
    Spread interrupts on allocation") the spreading of interrupts is
    dynamically performed at the time of allocation. Hence, there is no need
    for the drivers to enforce their own affinity for the spreading of
    interrupts.
    
    Also, irq_set_affinity_hint() applying the provided cpumask as an affinity
    for the interrupt is an undocumented side effect. To remove this side
    effect irq_set_affinity_hint() has been marked as deprecated and new
    interfaces have been introduced. Hence, replace the irq_set_affinity_hint()
    with the new interface irq_update_affinity_hint() that only sets the
    pointer for the affinity_hint.
    
    Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Link: https://lore.kernel.org/r/20210903152430.244937-4-nitesh@redhat.com
    Stable-dep-of: 915470e1b44e ("i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path")
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
IB/mlx5: Fix obj_type mismatch for SRQ event subscriptions [+ + +]
Author: Or Har-Toov <ohartoov@nvidia.com>
Date:   Wed Aug 13 15:43:20 2025 +0300

    IB/mlx5: Fix obj_type mismatch for SRQ event subscriptions
    
    [ Upstream commit 85fe9f565d2d5af95ac2bbaa5082b8ce62b039f5 ]
    
    Fix a bug where the driver's event subscription logic for SRQ-related
    events incorrectly sets obj_type for RMP objects.
    
    When subscribing to SRQ events, get_legacy_obj_type() did not handle
    the MLX5_CMD_OP_CREATE_RMP case, which caused obj_type to be 0
    (default).
    This led to a mismatch between the obj_type used during subscription
    (0) and the value used during notification (1, taken from the event's
    type field). As a result, event mapping for SRQ objects could fail and
    event notification would not be delivered correctly.
    
    This fix adds handling for MLX5_CMD_OP_CREATE_RMP in get_legacy_obj_type,
    returning MLX5_EVENT_QUEUE_TYPE_RQ so obj_type is consistent between
    subscription and notification.
    
    Fixes: 759738537142 ("IB/mlx5: Enable subscription for device events over DEVX")
    Link: https://patch.msgid.link/r/8f1048e3fdd1fde6b90607ce0ed251afaf8a148c.1755088962.git.leon@kernel.org
    Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
    Reviewed-by: Edward Srouji <edwards@nvidia.com>
    Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
    Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
igb: fix link test skipping when interface is admin down [+ + +]
Author: Kohei Enju <enjuk@amazon.com>
Date:   Fri Aug 15 15:26:31 2025 +0900

    igb: fix link test skipping when interface is admin down
    
    [ Upstream commit d709f178abca22a4d3642513df29afe4323a594b ]
    
    The igb driver incorrectly skips the link test when the network
    interface is admin down (if_running == false), causing the test to
    always report PASS regardless of the actual physical link state.
    
    This behavior is inconsistent with other drivers (e.g. i40e, ice, ixgbe,
    etc.) which correctly test the physical link state regardless of admin
    state.
    Remove the if_running check to ensure link test always reflects the
    physical link state.
    
    Fixes: 8d420a1b3ea6 ("igb: correct link test not being run when link is down")
    Signed-off-by: Kohei Enju <enjuk@amazon.com>
    Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
    Tested-by: Rinitha S <sx.rinitha@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>

 
KVM: SVM: Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active [+ + +]
Author: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
Date:   Sun Sep 21 20:07:39 2025 -0400

    KVM: SVM: Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active
    
    [ Upstream commit d02e48830e3fce9701265f6c5a58d9bdaf906a76 ]
    
    Commit 3bbf3565f48c ("svm: Do not intercept CR8 when enable AVIC")
    inhibited pre-VMRUN sync of TPR from LAPIC into VMCB::V_TPR in
    sync_lapic_to_cr8() when AVIC is active.
    
    AVIC does automatically sync between these two fields, however it does
    so only on explicit guest writes to one of these fields, not on a bare
    VMRUN.
    
    This meant that when AVIC is enabled host changes to TPR in the LAPIC
    state might not get automatically copied into the V_TPR field of VMCB.
    
    This is especially true when it is the userspace setting LAPIC state via
    KVM_SET_LAPIC ioctl() since userspace does not have access to the guest
    VMCB.
    
    Practice shows that it is the V_TPR that is actually used by the AVIC to
    decide whether to issue pending interrupts to the CPU (not TPR in TASKPRI),
    so any leftover value in V_TPR will cause serious interrupt delivery issues
    in the guest when AVIC is enabled.
    
    Fix this issue by doing pre-VMRUN TPR sync from LAPIC into VMCB::V_TPR
    even when AVIC is enabled.
    
    Fixes: 3bbf3565f48c ("svm: Do not intercept CR8 when enable AVIC")
    Cc: stable@vger.kernel.org
    Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
    Reviewed-by: Naveen N Rao (AMD) <naveen@kernel.org>
    Link: https://lore.kernel.org/r/c231be64280b1461e854e1ce3595d70cde3a2e9d.1756139678.git.maciej.szmigiero@oracle.com
    [sean: tag for stable@]
    Signed-off-by: Sean Christopherson <seanjc@google.com>
    [ Adjust context ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 5.4.300 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Thu Oct 2 13:34:35 2025 +0200

    Linux 5.4.300
    
    Link: https://lore.kernel.org/r/20250930143819.654157320@linuxfoundation.org
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Brett A C Sheffield <bacs@librecast.net>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Alok Tiwari <alok.a.tiwari@oracle.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/hugetlb: fix folio is still mapped when deleted [+ + +]
Author: Jinjiang Tu <tujinjiang@huawei.com>
Date:   Mon Sep 29 18:35:35 2025 -0400

    mm/hugetlb: fix folio is still mapped when deleted
    
    [ Upstream commit 7b7387650dcf2881fd8bb55bcf3c8bd6c9542dd7 ]
    
    Migration may be raced with fallocating hole.  remove_inode_single_folio
    will unmap the folio if the folio is still mapped.  However, it's called
    without folio lock.  If the folio is migrated and the mapped pte has been
    converted to migration entry, folio_mapped() returns false, and won't
    unmap it.  Due to extra refcount held by remove_inode_single_folio,
    migration fails, restores migration entry to normal pte, and the folio is
    mapped again.  As a result, we triggered BUG in filemap_unaccount_folio.
    
    The log is as follows:
     BUG: Bad page cache in process hugetlb  pfn:156c00
     page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00
     head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0
     aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file"
     flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff)
     page_type: f4(hugetlb)
     page dumped because: still mapped when deleted
     CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE
     Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
     Call Trace:
      <TASK>
      dump_stack_lvl+0x4f/0x70
      filemap_unaccount_folio+0xc4/0x1c0
      __filemap_remove_folio+0x38/0x1c0
      filemap_remove_folio+0x41/0xd0
      remove_inode_hugepages+0x142/0x250
      hugetlbfs_fallocate+0x471/0x5a0
      vfs_fallocate+0x149/0x380
    
    Hold folio lock before checking if the folio is mapped to avold race with
    migration.
    
    Link: https://lkml.kernel.org/r/20250912074139.3575005-1-tujinjiang@huawei.com
    Fixes: 4aae8d1c051e ("mm/hugetlbfs: unmap pages if page fault raced with hole punch")
    Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
    Cc: David Hildenbrand <david@redhat.com>
    Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
    Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
    Cc: Muchun Song <muchun.song@linux.dev>
    Cc: Oscar Salvador <osalvador@suse.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    [ folio -> page ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/khugepaged: fix the address passed to notifier on testing young [+ + +]
Author: Wei Yang <richard.weiyang@gmail.com>
Date:   Fri Aug 22 06:33:18 2025 +0000

    mm/khugepaged: fix the address passed to notifier on testing young
    
    commit 394bfac1c7f7b701c2c93834c5761b9c9ceeebcf upstream.
    
    Commit 8ee53820edfd ("thp: mmu_notifier_test_young") introduced
    mmu_notifier_test_young(), but we are passing the wrong address.
    In xxx_scan_pmd(), the actual iteration address is "_address" not
    "address".  We seem to misuse the variable on the very beginning.
    
    Change it to the right one.
    
    [akpm@linux-foundation.org fix whitespace, per everyone]
    Link: https://lkml.kernel.org/r/20250822063318.11644-1-richard.weiyang@gmail.com
    Fixes: 8ee53820edfd ("thp: mmu_notifier_test_young")
    Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
    Reviewed-by: Dev Jain <dev.jain@arm.com>
    Reviewed-by: Zi Yan <ziy@nvidia.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
    Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
    Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
    Cc: Nico Pache <npache@redhat.com>
    Cc: Ryan Roberts <ryan.roberts@arm.com>
    Cc: Barry Song <baohua@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>

 
mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory [+ + +]
Author: Miaohe Lin <linmiaohe@huawei.com>
Date:   Sun Sep 14 09:30:42 2025 -0400

    mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory
    
    [ Upstream commit d613f53c83ec47089c4e25859d5e8e0359f6f8da ]
    
    When I did memory failure tests, below panic occurs:
    
    page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))
    kernel BUG at include/linux/page-flags.h:616!
    Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40
    RIP: 0010:unpoison_memory+0x2f3/0x590
    RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246
    RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8
    RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0
    RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb
    R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000
    R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe
    FS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0
    Call Trace:
     <TASK>
     unpoison_memory+0x2f3/0x590
     simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110
     debugfs_attr_write+0x42/0x60
     full_proxy_write+0x5b/0x80
     vfs_write+0xd5/0x540
     ksys_write+0x64/0xe0
     do_syscall_64+0xb9/0x1d0
     entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f08f0314887
    RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887
    RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001
    RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff
    R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009
    R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00
     </TASK>
    Modules linked in: hwpoison_inject
    ---[ end trace 0000000000000000 ]---
    RIP: 0010:unpoison_memory+0x2f3/0x590
    RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246
    RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8
    RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0
    RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb
    R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000
    R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe
    FS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0
    Kernel panic - not syncing: Fatal exception
    Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
    ---[ end Kernel panic - not syncing: Fatal exception ]---
    
    The root cause is that unpoison_memory() tries to check the PG_HWPoison
    flags of an uninitialized page.  So VM_BUG_ON_PAGE(PagePoisoned(page)) is
    triggered.  This can be reproduced by below steps:
    
    1.Offline memory block:
    
     echo offline > /sys/devices/system/memory/memory12/state
    
    2.Get offlined memory pfn:
    
     page-types -b n -rlN
    
    3.Write pfn to unpoison-pfn
    
     echo <pfn> > /sys/kernel/debug/hwpoison/unpoison-pfn
    
    This scenario can be identified by pfn_to_online_page() returning NULL.
    And ZONE_DEVICE pages are never expected, so we can simply fail if
    pfn_to_online_page() == NULL to fix the bug.
    
    Link: https://lkml.kernel.org/r/20250828024618.1744895-1-linmiaohe@huawei.com
    Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online")
    Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
    Suggested-by: David Hildenbrand <david@redhat.com>
    Acked-by: David Hildenbrand <david@redhat.com>
    Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    [ Adjust context ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize() [+ + +]
Author: David Hildenbrand <david@redhat.com>
Date:   Mon Feb 10 17:13:17 2025 +0100

    mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()
    
    commit 41cddf83d8b00f29fd105e7a0777366edc69a5cf upstream.
    
    If migration succeeded, we called
    folio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from the
    old to the new folio.  This will set memcg_data of the old folio to 0.
    
    Similarly, if migration failed, memcg_data of the dst folio is left unset.
    
    If we call folio_putback_lru() on such folios (memcg_data == 0), we will
    add the folio to be freed to the LRU, making memcg code unhappy.  Running
    the hmm selftests:
    
      # ./hmm-tests
      ...
      #  RUN           hmm.hmm_device_private.migrate ...
      [  102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00
      [  102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff)
      [  102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9
      [  102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000
      [  102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled())
      [  102.087230][T14893] ------------[ cut here ]------------
      [  102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170
      [  102.090478][T14893] Modules linked in:
      [  102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151
      [  102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014
      [  102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170
      [  102.096104][T14893] Code: ...
      [  102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293
      [  102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426
      [  102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880
      [  102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000
      [  102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8
      [  102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000
      [  102.108830][T14893] FS:  00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000
      [  102.110643][T14893] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0
      [  102.113478][T14893] PKRU: 55555554
      [  102.114172][T14893] Call Trace:
      [  102.114805][T14893]  <TASK>
      [  102.115397][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170
      [  102.116547][T14893]  ? __warn.cold+0x110/0x210
      [  102.117461][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170
      [  102.118667][T14893]  ? report_bug+0x1b9/0x320
      [  102.119571][T14893]  ? handle_bug+0x54/0x90
      [  102.120494][T14893]  ? exc_invalid_op+0x17/0x50
      [  102.121433][T14893]  ? asm_exc_invalid_op+0x1a/0x20
      [  102.122435][T14893]  ? __wake_up_klogd.part.0+0x76/0xd0
      [  102.123506][T14893]  ? dump_page+0x4f/0x60
      [  102.124352][T14893]  ? folio_lruvec_lock_irqsave+0x10e/0x170
      [  102.125500][T14893]  folio_batch_move_lru+0xd4/0x200
      [  102.126577][T14893]  ? __pfx_lru_add+0x10/0x10
      [  102.127505][T14893]  __folio_batch_add_and_move+0x391/0x720
      [  102.128633][T14893]  ? __pfx_lru_add+0x10/0x10
      [  102.129550][T14893]  folio_putback_lru+0x16/0x80
      [  102.130564][T14893]  migrate_device_finalize+0x9b/0x530
      [  102.131640][T14893]  dmirror_migrate_to_device.constprop.0+0x7c5/0xad0
      [  102.133047][T14893]  dmirror_fops_unlocked_ioctl+0x89b/0xc80
    
    Likely, nothing else goes wrong: putting the last folio reference will
    remove the folio from the LRU again.  So besides memcg complaining, adding
    the folio to be freed to the LRU is just an unnecessary step.
    
    The new flow resembles what we have in migrate_folio_move(): add the dst
    to the lru, remove migration ptes, unlock and unref dst.
    
    Link: https://lkml.kernel.org/r/20250210161317.717936-1-david@redhat.com
    Fixes: 8763cb45ab96 ("mm/migrate: new memory migration helper for use with device memory")
    Signed-off-by: David Hildenbrand <david@redhat.com>
    Cc: Jérôme Glisse <jglisse@redhat.com>
    Cc: John Hubbard <jhubbard@nvidia.com>
    Cc: Alistair Popple <apopple@nvidia.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>

 
mmc: mvsdio: Fix dma_unmap_sg() nents value [+ + +]
Author: Thomas Fourier <fourier.thomas@gmail.com>
Date:   Tue Aug 26 09:58:08 2025 +0200

    mmc: mvsdio: Fix dma_unmap_sg() nents value
    
    commit 8ab2f1c35669bff7d7ed1bb16bf5cc989b3e2e17 upstream.
    
    The dma_unmap_sg() functions should be called with the same nents as the
    dma_map_sg(), not the value the map function returned.
    
    Fixes: 236caa7cc351 ("mmc: SDIO driver for Marvell SoCs")
    Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Cc: stable@vger.kernel.org
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
mtd: nand: raw: atmel: Fix comment in timings preparation [+ + +]
Author: Alexander Dahl <ada@thorsis.com>
Date:   Sat Sep 13 11:23:06 2025 -0400

    mtd: nand: raw: atmel: Fix comment in timings preparation
    
    [ Upstream commit 1c60e027ffdebd36f4da766d9c9abbd1ea4dd8f9 ]
    
    Looks like a copy'n'paste mistake introduced when initially adding the
    dynamic timings feature with commit f9ce2eddf176 ("mtd: nand: atmel: Add
    ->setup_data_interface() hooks").  The context around this and
    especially the code itself suggests 'read' is meant instead of write.
    
    Signed-off-by: Alexander Dahl <ada@thorsis.com>
    Reviewed-by: Nicolas Ferre <nicolas.ferre@microchip.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/20240226122537.75097-1-ada@thorsis.com
    Stable-dep-of: fd779eac2d65 ("mtd: nand: raw: atmel: Respect tAR, tCLR in read setup timing")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mtd: nand: raw: atmel: Respect tAR, tCLR in read setup timing [+ + +]
Author: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Date:   Sat Sep 13 11:23:07 2025 -0400

    mtd: nand: raw: atmel: Respect tAR, tCLR in read setup timing
    
    [ Upstream commit fd779eac2d659668be4d3dbdac0710afd5d6db12 ]
    
    Having setup time 0 violates tAR, tCLR of some chips, for instance
    TOSHIBA TC58NVG2S3ETAI0 cannot be detected successfully (first ID byte
    being read duplicated, i.e. 98 98 dc 90 15 76 14 03 instead of
    98 dc 90 15 76 ...).
    
    Atmel Application Notes postulated 1 cycle NRD_SETUP without explanation
    [1], but it looks more appropriate to just calculate setup time properly.
    
    [1] Link: https://ww1.microchip.com/downloads/aemDocuments/documents/MPU32/ApplicationNotes/ApplicationNotes/doc6255.pdf
    
    Cc: stable@vger.kernel.org
    Fixes: f9ce2eddf176 ("mtd: nand: atmel: Add ->setup_data_interface() hooks")
    Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
    Tested-by: Alexander Dahl <ada@thorsis.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer [+ + +]
Author: Christophe Kerello <christophe.kerello@foss.st.com>
Date:   Sat Sep 13 12:13:49 2025 -0400

    mtd: rawnand: stm32_fmc2: avoid overlapping mappings on ECC buffer
    
    [ Upstream commit 513c40e59d5a414ab763a9c84797534b5e8c208d ]
    
    Avoid below overlapping mappings by using a contiguous
    non-cacheable buffer.
    
    [    4.077708] DMA-API: stm32_fmc2_nfc 48810000.nand-controller: cacheline tracking EEXIST,
    overlapping mappings aren't supported
    [    4.089103] WARNING: CPU: 1 PID: 44 at kernel/dma/debug.c:568 add_dma_entry+0x23c/0x300
    [    4.097071] Modules linked in:
    [    4.100101] CPU: 1 PID: 44 Comm: kworker/u4:2 Not tainted 6.1.82 #1
    [    4.106346] Hardware name: STMicroelectronics STM32MP257F VALID1 SNOR / MB1704 (LPDDR4 Power discrete) + MB1703 + MB1708 (SNOR MB1730) (DT)
    [    4.118824] Workqueue: events_unbound deferred_probe_work_func
    [    4.124674] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    [    4.131624] pc : add_dma_entry+0x23c/0x300
    [    4.135658] lr : add_dma_entry+0x23c/0x300
    [    4.139792] sp : ffff800009dbb490
    [    4.143016] x29: ffff800009dbb4a0 x28: 0000000004008022 x27: ffff8000098a6000
    [    4.150174] x26: 0000000000000000 x25: ffff8000099e7000 x24: ffff8000099e7de8
    [    4.157231] x23: 00000000ffffffff x22: 0000000000000000 x21: ffff8000098a6a20
    [    4.164388] x20: ffff000080964180 x19: ffff800009819ba0 x18: 0000000000000006
    [    4.171545] x17: 6361727420656e69 x16: 6c6568636163203a x15: 72656c6c6f72746e
    [    4.178602] x14: 6f632d646e616e2e x13: ffff800009832f58 x12: 00000000000004ec
    [    4.185759] x11: 00000000000001a4 x10: ffff80000988af58 x9 : ffff800009832f58
    [    4.192916] x8 : 00000000ffffefff x7 : ffff80000988af58 x6 : 80000000fffff000
    [    4.199972] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
    [    4.207128] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000812d2c40
    [    4.214185] Call trace:
    [    4.216605]  add_dma_entry+0x23c/0x300
    [    4.220338]  debug_dma_map_sg+0x198/0x350
    [    4.224373]  __dma_map_sg_attrs+0xa0/0x110
    [    4.228411]  dma_map_sg_attrs+0x10/0x2c
    [    4.232247]  stm32_fmc2_nfc_xfer.isra.0+0x1c8/0x3fc
    [    4.237088]  stm32_fmc2_nfc_seq_read_page+0xc8/0x174
    [    4.242127]  nand_read_oob+0x1d4/0x8e0
    [    4.245861]  mtd_read_oob_std+0x58/0x84
    [    4.249596]  mtd_read_oob+0x90/0x150
    [    4.253231]  mtd_read+0x68/0xac
    
    Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
    Cc: stable@vger.kernel.org
    Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver")
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    [ adapted variable name from nfc to fmc2 throughout the patch ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mtd: rawnand: stm32_fmc2: fix ECC overwrite [+ + +]
Author: Christophe Kerello <christophe.kerello@foss.st.com>
Date:   Tue Aug 12 09:30:08 2025 +0200

    mtd: rawnand: stm32_fmc2: fix ECC overwrite
    
    commit 811c0da4542df3c065f6cb843ced68780e27bb44 upstream.
    
    In case OOB write is requested during a data write, ECC is currently
    lost. Avoid this issue by only writing in the free spare area.
    This issue has been seen with a YAFFS2 file system.
    
    Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com>
    Cc: stable@vger.kernel.org
    Fixes: 2cd457f328c1 ("mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver")
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable() [+ + +]
Author: Stefan Wahren <wahrenst@gmx.net>
Date:   Thu Sep 4 11:13:34 2025 +0200

    net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()
    
    [ Upstream commit 03e79de4608bdd48ad6eec272e196124cefaf798 ]
    
    The function of_phy_find_device may return NULL, so we need to take
    care before dereferencing phy_dev.
    
    Fixes: 64a632da538a ("net: fec: Fix phy_device lookup for phy_reset_after_clk_enable()")
    Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
    Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com>
    Cc: Richard Leitner <richard.leitner@skidata.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Reviewed-by: Wei Fang <wei.fang@nxp.com>
    Link: https://patch.msgid.link/20250904091334.53965-1-wahrenst@gmx.net
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@google.com>
Date:   Mon Apr 7 09:33:11 2025 -0700

    net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.
    
    commit 0bb2f7a1ad1f11d861f58e5ee5051c8974ff9569 upstream.
    
    When I ran the repro [0] and waited a few seconds, I observed two
    LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]
    
    Reproduction Steps:
    
      1) Mount CIFS
      2) Add an iptables rule to drop incoming FIN packets for CIFS
      3) Unmount CIFS
      4) Unload the CIFS module
      5) Remove the iptables rule
    
    At step 3), the CIFS module calls sock_release() for the underlying
    TCP socket, and it returns quickly.  However, the socket remains in
    FIN_WAIT_1 because incoming FIN packets are dropped.
    
    At this point, the module's refcnt is 0 while the socket is still
    alive, so the following rmmod command succeeds.
    
      # ss -tan
      State      Recv-Q Send-Q Local Address:Port  Peer Address:Port
      FIN-WAIT-1 0      477        10.0.2.15:51062   10.0.0.137:445
    
      # lsmod | grep cifs
      cifs                 1159168  0
    
    This highlights a discrepancy between the lifetime of the CIFS module
    and the underlying TCP socket.  Even after CIFS calls sock_release()
    and it returns, the TCP socket does not die immediately in order to
    close the connection gracefully.
    
    While this is generally fine, it causes an issue with LOCKDEP because
    CIFS assigns a different lock class to the TCP socket's sk->sk_lock
    using sock_lock_init_class_and_name().
    
    Once an incoming packet is processed for the socket or a timer fires,
    sk->sk_lock is acquired.
    
    Then, LOCKDEP checks the lock context in check_wait_context(), where
    hlock_class() is called to retrieve the lock class.  However, since
    the module has already been unloaded, hlock_class() logs a warning
    and returns NULL, triggering the null-ptr-deref.
    
    If LOCKDEP is enabled, we must ensure that a module calling
    sock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloaded
    while such a socket is still alive to prevent this issue.
    
    Let's hold the module reference in sock_lock_init_class_and_name()
    and release it when the socket is freed in sk_prot_free().
    
    Note that sock_lock_init() clears sk->sk_owner for svc_create_socket()
    that calls sock_lock_init_class_and_name() for a listening socket,
    which clones a socket by sk_clone_lock() without GFP_ZERO.
    
    [0]:
    CIFS_SERVER="10.0.0.137"
    CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST"
    DEV="enp0s3"
    CRED="/root/WindowsCredential.txt"
    
    MNT=$(mktemp -d /tmp/XXXXXX)
    mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1
    
    iptables -A INPUT -s ${CIFS_SERVER} -j DROP
    
    for i in $(seq 10);
    do
        umount ${MNT}
        rmmod cifs
        sleep 1
    done
    
    rm -r ${MNT}
    
    iptables -D INPUT -s ${CIFS_SERVER} -j DROP
    
    [1]:
    DEBUG_LOCKS_WARN_ON(1)
    WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)
    Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]
    CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)
    ...
    Call Trace:
     <IRQ>
     __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178)
     lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816)
     _raw_spin_lock_nested (kernel/locking/spinlock.c:379)
     tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350)
    ...
    
    BUG: kernel NULL pointer dereference, address: 00000000000000c4
     PF: supervisor read access in kernel mode
     PF: error_code(0x0000) - not-present page
    PGD 0
    Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G        W          6.14.0 #36
    Tainted: [W]=WARN
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
    RIP: 0010:__lock_acquire (kernel/locking/lockdep.c:4852 kernel/locking/lockdep.c:5178)
    Code: 15 41 09 c7 41 8b 44 24 20 25 ff 1f 00 00 41 09 c7 8b 84 24 a0 00 00 00 45 89 7c 24 20 41 89 44 24 24 e8 e1 bc ff ff 4c 89 e7 <44> 0f b6 b8 c4 00 00 00 e8 d1 bc ff ff 0f b6 80 c5 00 00 00 88 44
    RSP: 0018:ffa0000000468a10 EFLAGS: 00010046
    RAX: 0000000000000000 RBX: ff1100010091cc38 RCX: 0000000000000027
    RDX: ff1100081f09ca48 RSI: 0000000000000001 RDI: ff1100010091cc88
    RBP: ff1100010091c200 R08: ff1100083fe6e228 R09: 00000000ffffbfff
    R10: ff1100081eca0000 R11: ff1100083fe10dc0 R12: ff1100010091cc88
    R13: 0000000000000001 R14: 0000000000000000 R15: 00000000000424b1
    FS:  0000000000000000(0000) GS:ff1100081f080000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00000000000000c4 CR3: 0000000002c4a003 CR4: 0000000000771ef0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     <IRQ>
     lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816)
     _raw_spin_lock_nested (kernel/locking/spinlock.c:379)
     tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350)
     ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205 (discriminator 1))
     ip_local_deliver_finish (./include/linux/rcupdate.h:878 net/ipv4/ip_input.c:234)
     ip_sublist_rcv_finish (net/ipv4/ip_input.c:576)
     ip_list_rcv_finish (net/ipv4/ip_input.c:628)
     ip_list_rcv (net/ipv4/ip_input.c:670)
     __netif_receive_skb_list_core (net/core/dev.c:5939 net/core/dev.c:5986)
     netif_receive_skb_list_internal (net/core/dev.c:6040 net/core/dev.c:6129)
     napi_complete_done (./include/linux/list.h:37 ./include/net/gro.h:519 ./include/net/gro.h:514 net/core/dev.c:6496)
     e1000_clean (drivers/net/ethernet/intel/e1000/e1000_main.c:3815)
     __napi_poll.constprop.0 (net/core/dev.c:7191)
     net_rx_action (net/core/dev.c:7262 net/core/dev.c:7382)
     handle_softirqs (kernel/softirq.c:561)
     __irq_exit_rcu (kernel/softirq.c:596 kernel/softirq.c:435 kernel/softirq.c:662)
     irq_exit_rcu (kernel/softirq.c:680)
     common_interrupt (arch/x86/kernel/irq.c:280 (discriminator 14))
      </IRQ>
     <TASK>
     asm_common_interrupt (./arch/x86/include/asm/idtentry.h:693)
    RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:744)
    Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d c3 2b 15 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90
    RSP: 0018:ffa00000000ffee8 EFLAGS: 00000202
    RAX: 000000000000640b RBX: ff1100010091c200 RCX: 0000000000061aa4
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff812f30c5
    RBP: 000000000000000a R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000001 R11: 0000000000000002 R12: 0000000000000000
    R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
     ? do_idle (kernel/sched/idle.c:186 kernel/sched/idle.c:325)
     default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118)
     do_idle (kernel/sched/idle.c:186 kernel/sched/idle.c:325)
     cpu_startup_entry (kernel/sched/idle.c:422 (discriminator 1))
     start_secondary (arch/x86/kernel/smpboot.c:315)
     common_startup_64 (arch/x86/kernel/head_64.S:421)
     </TASK>
    Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]
    CR2: 00000000000000c4
    
    Fixes: ed07536ed673 ("[PATCH] lockdep: annotate nfs/nfsd in-kernel sockets")
    Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
    Cc: stable@vger.kernel.org
    Link: https://patch.msgid.link/20250407163313.22682-1-kuniyu@amazon.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    [ no ns_tracker and sk_user_frags fields ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: liquidio: fix overflow in octeon_init_instr_queue() [+ + +]
Author: Alexey Nepomnyashih <sdl@nppct.ru>
Date:   Wed Sep 17 15:30:58 2025 +0000

    net: liquidio: fix overflow in octeon_init_instr_queue()
    
    [ Upstream commit cca7b1cfd7b8a0eff2a3510c5e0f10efe8fa3758 ]
    
    The expression `(conf->instr_type == 64) << iq_no` can overflow because
    `iq_no` may be as high as 64 (`CN23XX_MAX_RINGS_PER_PF`). Casting the
    operand to `u64` ensures correct 64-bit arithmetic.
    
    Fixes: f21fb3ed364b ("Add support of Cavium Liquidio ethernet adapters")
    Signed-off-by: Alexey Nepomnyashih <sdl@nppct.ru>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: natsemi: fix `rx_dropped` double accounting on `netif_rx()` failure [+ + +]
Author: Yeounsu Moon <yyyynoom@gmail.com>
Date:   Sat Sep 13 15:01:36 2025 +0900

    net: natsemi: fix `rx_dropped` double accounting on `netif_rx()` failure
    
    [ Upstream commit 93ab4881a4e2b9657bdce4b8940073bfb4ed5eab ]
    
    `netif_rx()` already increments `rx_dropped` core stat when it fails.
    The driver was also updating `ndev->stats.rx_dropped` in the same path.
    Since both are reported together via `ip -s -s` command, this resulted
    in drops being counted twice in user-visible stats.
    
    Keep the driver update on `if (unlikely(!skb))`, but skip it after
    `netif_rx()` errors.
    
    Fixes: caf586e5f23c ("net: add a core netdev->rx_dropped counter")
    Signed-off-by: Yeounsu Moon <yyyynoom@gmail.com>
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20250913060135.35282-3-yyyynoom@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

net: rfkill: gpio: add DT support [+ + +]
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date:   Sun Sep 21 20:06:36 2025 -0400

    net: rfkill: gpio: add DT support
    
    [ Upstream commit d64c732dfc9edcd57feb693c23162117737e426b ]
    
    Allow probing rfkill-gpio via device tree. This hooks up the already
    existing support that was started in commit 262c91ee5e52 ("net:
    rfkill: gpio: prepare for DT and ACPI support") via the "rfkill-gpio"
    compatible, with the "name" and "type" properties renamed to "label"
    and "radio-type", respectively, in the device tree case.
    
    Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
    Link: https://lore.kernel.org/r/20230102-rfkill-gpio-dt-v2-2-d1b83758c16d@pengutronix.de
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Stable-dep-of: b6f56a44e4c1 ("net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer [+ + +]
Author: Hans de Goede <hansg@kernel.org>
Date:   Sun Sep 21 20:06:37 2025 -0400

    net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer
    
    [ Upstream commit b6f56a44e4c1014b08859dcf04ed246500e310e5 ]
    
    Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from
    device property") rfkill_find_type() gets called with the possibly
    uninitialized "const char *type_name;" local variable.
    
    On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"
    acpi_device, the rfkill->type is set based on the ACPI acpi_device_id:
    
            rfkill->type = (unsigned)id->driver_data;
    
    and there is no "type" property so device_property_read_string() will fail
    and leave type_name uninitialized, leading to a potential crash.
    
    rfkill_find_type() does accept a NULL pointer, fix the potential crash
    by initializing type_name to NULL.
    
    Note likely sofar this has not been caught because:
    
    1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device
    2. The stack happened to contain NULL where type_name is stored
    
    Fixes: 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property")
    Cc: stable@vger.kernel.org
    Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Signed-off-by: Hans de Goede <hansg@kernel.org>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Link: https://patch.msgid.link/20250913113515.21698-1-hansg@kernel.org
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
NFSv4: Don't clear capabilities that won't be reset [+ + +]
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Aug 29 09:02:16 2025 -0700

    NFSv4: Don't clear capabilities that won't be reset
    
    [ Upstream commit 31f1a960ad1a14def94fa0b8c25d62b4c032813f ]
    
    Don't clear the capabilities that are not going to get reset by the call
    to _nfs4_server_capabilities().
    
    Reported-by: Scott Haiden <scott.b.haiden@gmail.com>
    Fixes: b01f21cacde9 ("NFS: Fix the setting of capabilities when automounting a new filesystem")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
nilfs2: fix CFI failure when accessing /sys/fs/nilfs2/features/* [+ + +]
Author: Nathan Chancellor <nathan@kernel.org>
Date:   Sat Sep 6 23:43:34 2025 +0900

    nilfs2: fix CFI failure when accessing /sys/fs/nilfs2/features/*
    
    commit 025e87f8ea2ae3a28bf1fe2b052bfa412c27ed4a upstream.
    
    When accessing one of the files under /sys/fs/nilfs2/features when
    CONFIG_CFI_CLANG is enabled, there is a CFI violation:
    
      CFI failure at kobj_attr_show+0x59/0x80 (target: nilfs_feature_revision_show+0x0/0x30; expected type: 0xfc392c4d)
      ...
      Call Trace:
       <TASK>
       sysfs_kf_seq_show+0x2a6/0x390
       ? __cfi_kobj_attr_show+0x10/0x10
       kernfs_seq_show+0x104/0x15b
       seq_read_iter+0x580/0xe2b
      ...
    
    When the kobject of the kset for /sys/fs/nilfs2 is initialized, its ktype
    is set to kset_ktype, which has a ->sysfs_ops of kobj_sysfs_ops.  When
    nilfs_feature_attr_group is added to that kobject via
    sysfs_create_group(), the kernfs_ops of each files is sysfs_file_kfops_rw,
    which will call sysfs_kf_seq_show() when ->seq_show() is called.
    sysfs_kf_seq_show() in turn calls kobj_attr_show() through
    ->sysfs_ops->show().  kobj_attr_show() casts the provided attribute out to
    a 'struct kobj_attribute' via container_of() and calls ->show(), resulting
    in the CFI violation since neither nilfs_feature_revision_show() nor
    nilfs_feature_README_show() match the prototype of ->show() in 'struct
    kobj_attribute'.
    
    Resolve the CFI violation by adjusting the second parameter in
    nilfs_feature_{revision,README}_show() from 'struct attribute' to 'struct
    kobj_attribute' to match the expected prototype.
    
    Link: https://lkml.kernel.org/r/20250906144410.22511-1-konishi.ryusuke@gmail.com
    Fixes: aebe17f68444 ("nilfs2: add /sys/fs/nilfs2/features group")
    Signed-off-by: Nathan Chancellor <nathan@kernel.org>
    Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
    Reported-by: kernel test robot <oliver.sang@intel.com>
    Closes: https://lore.kernel.org/oe-lkp/202509021646.bc78d9ef-lkp@intel.com/
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
ocfs2: fix recursive semaphore deadlock in fiemap call [+ + +]
Author: Mark Tinguely <mark.tinguely@oracle.com>
Date:   Fri Aug 29 10:18:15 2025 -0500

    ocfs2: fix recursive semaphore deadlock in fiemap call
    
    commit 04100f775c2ea501927f508f17ad824ad1f23c8d upstream.
    
    syzbot detected a OCFS2 hang due to a recursive semaphore on a
    FS_IOC_FIEMAP of the extent list on a specially crafted mmap file.
    
    context_switch kernel/sched/core.c:5357 [inline]
       __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961
       __schedule_loop kernel/sched/core.c:7043 [inline]
       schedule+0x165/0x360 kernel/sched/core.c:7058
       schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115
       rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185
       __down_write_common kernel/locking/rwsem.c:1317 [inline]
       __down_write kernel/locking/rwsem.c:1326 [inline]
       down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591
       ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142
       do_page_mkwrite+0x14d/0x310 mm/memory.c:3361
       wp_page_shared mm/memory.c:3762 [inline]
       do_wp_page+0x268d/0x5800 mm/memory.c:3981
       handle_pte_fault mm/memory.c:6068 [inline]
       __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195
       handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364
       do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387
       handle_page_fault arch/x86/mm/fault.c:1476 [inline]
       exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532
       asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623
    RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]
    RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]
    RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]
    RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26
    Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89
    f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 <f3> a4 0f
    1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41
    RSP: 0018:ffffc9000403f950 EFLAGS: 00050256
    RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038
    RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060
    RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42
    R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098
    R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060
       copy_to_user include/linux/uaccess.h:225 [inline]
       fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145
       ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806
       ioctl_fiemap fs/ioctl.c:220 [inline]
       do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532
       __do_sys_ioctl fs/ioctl.c:596 [inline]
       __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584
       do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
       do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
    RIP: 0033:0x7f5f13850fd9
    RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
    RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9
    RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004
    RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0
    R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03b
    
    ocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (since
    v2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read the
    extent list of this running mmap executable.  The user supplied buffer to
    hold the fiemap information page faults calling ocfs2_page_mkwrite() which
    will take a write lock (since v2.6.27-38-g00dc417fa3e7) of the same
    semaphore.  This recursive semaphore will hold filesystem locks and causes
    a hang of the fileystem.
    
    The ip_alloc_sem protects the inode extent list and size.  Release the
    read semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()
    and ocfs2_fiemap_inline().  This does an unnecessary semaphore lock/unlock
    on the last extent but simplifies the error path.
    
    Link: https://lkml.kernel.org/r/61d1a62b-2631-4f12-81e2-cd689914360b@oracle.com
    Fixes: 00dc417fa3e7 ("ocfs2: fiemap support")
    Signed-off-by: Mark Tinguely <mark.tinguely@oracle.com>
    Reported-by: syzbot+541dcc6ee768f77103e7@syzkaller.appspotmail.com
    Closes: https://syzkaller.appspot.com/bug?extid=541dcc6ee768f77103e7
    Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
    Cc: Mark Fasheh <mark@fasheh.com>
    Cc: Joel Becker <jlbec@evilplan.org>
    Cc: Junxiao Bi <junxiao.bi@oracle.com>
    Cc: Changwei Ge <gechangwei@live.cn>
    Cc: Jun Piao <piaojun@huawei.com>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
pcmcia: omap_cf: Mark driver struct with __refdata to prevent section mismatch [+ + +]
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Wed Aug 13 17:50:14 2025 +0200

    pcmcia: omap_cf: Mark driver struct with __refdata to prevent section mismatch
    
    [ Upstream commit d1dfcdd30140c031ae091868fb5bed084132bca1 ]
    
    As described in the added code comment, a reference to .exit.text is ok
    for drivers registered via platform_driver_probe().  Make this explicit
    to prevent the following section mismatch warning
    
        WARNING: modpost: drivers/pcmcia/omap_cf: section mismatch in reference: omap_cf_driver+0x4 (section: .data) -> omap_cf_remove (section: .exit.text)
    
    that triggers on an omap1_defconfig + CONFIG_OMAP_CF=m build.
    
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
    Reviewed-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
    Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
phy: ti-pipe3: fix device leak at unbind [+ + +]
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Jul 24 15:12:06 2025 +0200

    phy: ti-pipe3: fix device leak at unbind
    
    commit e19bcea99749ce8e8f1d359f68ae03210694ad56 upstream.
    
    Make sure to drop the reference to the control device taken by
    of_find_device_by_node() during probe when the driver is unbound.
    
    Fixes: 918ee0d21ba4 ("usb: phy: omap-usb3: Don't use omap_get_control_dev()")
    Cc: stable@vger.kernel.org      # 3.13
    Cc: Roger Quadros <rogerq@kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20250724131206.2211-4-johan@kernel.org
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
power: supply: bq27xxx: fix error return in case of no bq27000 hdq battery [+ + +]
Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Sat Aug 23 12:34:56 2025 +0200

    power: supply: bq27xxx: fix error return in case of no bq27000 hdq battery
    
    commit 2c334d038466ac509468fbe06905a32d202117db upstream.
    
    Since commit
    
            commit f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy")
    
    the console log of some devices with hdq enabled but no bq27000 battery
    (like e.g. the Pandaboard) is flooded with messages like:
    
    [   34.247833] power_supply bq27000-battery: driver failed to report 'status' property: -1
    
    as soon as user-space is finding a /sys entry and trying to read the
    "status" property.
    
    It turns out that the offending commit changes the logic to now return the
    value of cache.flags if it is <0. This is likely under the assumption that
    it is an error number. In normal errors from bq27xxx_read() this is indeed
    the case.
    
    But there is special code to detect if no bq27000 is installed or accessible
    through hdq/1wire and wants to report this. In that case, the cache.flags
    are set historically by
    
            commit 3dd843e1c26a ("bq27000: report missing device better.")
    
    to constant -1 which did make reading properties return -ENODEV. So everything
    appeared to be fine before the return value was passed upwards.
    
    Now the -1 is returned as -EPERM instead of -ENODEV, triggering the error
    condition in power_supply_format_property() which then floods the console log.
    
    So we change the detection of missing bq27000 battery to simply set
    
            cache.flags = -ENODEV
    
    instead of -1.
    
    Fixes: f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy")
    Cc: Jerry Lv <Jerry.Lv@axis.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
    Link: https://lore.kernel.org/r/692f79eb6fd541adb397038ea6e750d4de2deddf.1755945297.git.hns@goldelico.com
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

power: supply: bq27xxx: restrict no-battery detection to bq27000 [+ + +]
Author: H. Nikolaus Schaller <hns@goldelico.com>
Date:   Sat Aug 23 12:34:57 2025 +0200

    power: supply: bq27xxx: restrict no-battery detection to bq27000
    
    commit 1e451977e1703b6db072719b37cd1b8e250b9cc9 upstream.
    
    There are fuel gauges in the bq27xxx series (e.g. bq27z561) which may in some
    cases report 0xff as the value of BQ27XXX_REG_FLAGS that should not be
    interpreted as "no battery" like for a disconnected battery with some built
    in bq27000 chip.
    
    So restrict the no-battery detection originally introduced by
    
        commit 3dd843e1c26a ("bq27000: report missing device better.")
    
    to the bq27000.
    
    There is no need to backport further because this was hidden before
    
            commit f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy")
    
    Fixes: f16d9fb6cf03 ("power: supply: bq27xxx: Retrieve again when busy")
    Suggested-by: Jerry Lv <Jerry.Lv@axis.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
    Link: https://lore.kernel.org/r/dd979fa6855fd051ee5117016c58daaa05966e24.1755945297.git.hns@goldelico.com
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
rds: ib: Increment i_fastreg_wrs before bailing out [+ + +]
Author: Håkon Bugge <haakon.bugge@oracle.com>
Date:   Thu Sep 11 15:33:34 2025 +0200

    rds: ib: Increment i_fastreg_wrs before bailing out
    
    commit 4351ca3fcb3ffecf12631b4996bf085a2dad0db6 upstream.
    
    We need to increment i_fastreg_wrs before we bail out from
    rds_ib_post_reg_frmr().
    
    We have a fixed budget of how many FRWR operations that can be
    outstanding using the dedicated QP used for memory registrations and
    de-registrations. This budget is enforced by the atomic_t
    i_fastreg_wrs. If we bail out early in rds_ib_post_reg_frmr(), we will
    "leak" the possibility of posting an FRWR operation, and if that
    accumulates, no FRWR operation can be carried out.
    
    Fixes: 1659185fb4d0 ("RDS: IB: Support Fastreg MR (FRMR) memory registration mode")
    Fixes: 3a2886cca703 ("net/rds: Keep track of and wait for FRWR segments in use upon shutdown")
    Cc: stable@vger.kernel.org
    Signed-off-by: Håkon Bugge <haakon.bugge@oracle.com>
    Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
    Link: https://patch.msgid.link/20250911133336.451212-1-haakon.bugge@oracle.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Revert "net/mlx5e: Update and set Xon/Xoff upon port speed set" [+ + +]
Author: Tariq Toukan <tariqt@nvidia.com>
Date:   Wed Sep 17 16:48:54 2025 +0300

    Revert "net/mlx5e: Update and set Xon/Xoff upon port speed set"
    
    [ Upstream commit 3fbfe251cc9f6d391944282cdb9bcf0bd02e01f8 ]
    
    This reverts commit d24341740fe48add8a227a753e68b6eedf4b385a.
    It causes errors when trying to configure QoS, as well as
    loss of L2 connectivity (on multi-host devices).
    
    Reported-by: Jakub Kicinski <kuba@kernel.org>
    Link: https://lore.kernel.org/20250910170011.70528106@kernel.org
    Fixes: d24341740fe4 ("net/mlx5e: Update and set Xon/Xoff upon port speed set")
    Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
serial: sc16is7xx: fix bug in flow control levels init [+ + +]
Author: Hugo Villeneuve <hvilleneuve@dimonoff.com>
Date:   Wed Sep 17 09:03:19 2025 -0400

    serial: sc16is7xx: fix bug in flow control levels init
    
    [ Upstream commit 535fd4c98452c87537a40610abba45daf5761ec6 ]
    
    When trying to set MCR[2], XON1 is incorrectly accessed instead. And when
    writing to the TCR register to configure flow control levels, we are
    incorrectly writing to the MSR register. The default value of $00 is then
    used for TCR, which means that selectable trigger levels in FCR are used
    in place of TCR.
    
    TCR/TLR access requires EFR[4] (enable enhanced functions) and MCR[2]
    to be set. EFR[4] is already set in probe().
    
    MCR access requires LCR[7] to be zero.
    
    Since LCR is set to $BF when trying to set MCR[2], XON1 is incorrectly
    accessed instead because MCR shares the same address space as XON1.
    
    Since MCR[2] is unmodified and still zero, when writing to TCR we are in
    fact writing to MSR because TCR/TLR registers share the same address space
    as MSR/SPR.
    
    Fix by first removing useless reconfiguration of EFR[4] (enable enhanced
    functions), as it is already enabled in sc16is7xx_probe() since commit
    43c51bb573aa ("sc16is7xx: make sure device is in suspend once probed").
    Now LCR is $00, which means that MCR access is enabled.
    
    Also remove regcache_cache_bypass() calls since we no longer access the
    enhanced registers set, and TCR is already declared as volatile (in fact
    by declaring MSR as volatile, which shares the same address).
    
    Finally disable access to TCR/TLR registers after modifying them by
    clearing MCR[2].
    
    Note: the comment about "... and internal clock div" is wrong and can be
          ignored/removed as access to internal clock div registers (DLL/DLH)
          is permitted only when LCR[7] is logic 1, not when enhanced features
          is enabled. And DLL/DLH access is not needed in sc16is7xx_startup().
    
    Fixes: dfeae619d781 ("serial: sc16is7xx")
    Cc: stable@vger.kernel.org
    Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
    Link: https://lore.kernel.org/r/20250731124451.1108864-1-hugo@hugovil.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    [ s->regmap renames + context ]
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
soc: qcom: mdt_loader: Deal with zero e_shentsize [+ + +]
Author: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Date:   Wed Jul 30 15:51:51 2025 -0500

    soc: qcom: mdt_loader: Deal with zero e_shentsize
    
    commit 25daf9af0ac1bf12490b723b5efaf8dcc85980bc upstream.
    
    Firmware that doesn't provide section headers leave both e_shentsize and
    e_shnum 0, which obvious isn't compatible with the newly introduced
    stricter checks.
    
    Make the section-related checks conditional on either of these values
    being non-zero.
    
    Fixes: 9f9967fed9d0 ("soc: qcom: mdt_loader: Ensure we don't read past the ELF header")
    Reported-by: Val Packett <val@packett.cool>
    Closes: https://lore.kernel.org/all/ece307c3-7d65-440f-babd-88cf9705b908@packett.cool/
    Reported-by: Neil Armstrong <neil.armstrong@linaro.org>
    Closes: https://lore.kernel.org/all/aec9cd03-6fc2-4dc8-b937-8b7cf7bf4128@linaro.org/
    Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
    Fixes: 9f35ab0e53cc ("soc: qcom: mdt_loader: Fix error return values in mdt_header_valid()")
    Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
    Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/20250730-mdt-loader-shentsize-zero-v1-1-04f43186229c@oss.qualcomm.com
    Signed-off-by: Bjorn Andersson <andersson@kernel.org>
    Cc: Yongqin Liu <yongqin.liu@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect(). [+ + +]
Author: Kuniyuki Iwashima <kuniyu@google.com>
Date:   Mon Sep 15 17:56:46 2025 +0000

    tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().
    
    [ Upstream commit 45c8a6cc2bcd780e634a6ba8e46bffbdf1fc5c01 ]
    
    syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk
    in the TCP_ESTABLISHED state. [0]
    
    syzbot reused the server-side TCP Fast Open socket as a new client before
    the TFO socket completes 3WHS:
    
      1. accept()
      2. connect(AF_UNSPEC)
      3. connect() to another destination
    
    As of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes
    it to TCP_CLOSE and makes connect() possible, which restarts timers.
    
    Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the
    retransmit timer triggered the warning and the intended packet was not
    retransmitted.
    
    Let's call reqsk_fastopen_remove() in tcp_disconnect().
    
    [0]:
    WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
    Modules linked in:
    CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
    RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))
    Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e
    RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293
    RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017
    RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400
    RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8
    R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540
    R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0
    FS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0
    Call Trace:
     <IRQ>
     tcp_write_timer (net/ipv4/tcp_timer.c:738)
     call_timer_fn (kernel/time/timer.c:1747)
     __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)
     timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)
     tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)
     __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))
     tmigr_handle_remote (kernel/time/timer_migration.c:1096)
     handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)
     irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)
     sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))
     </IRQ>
    
    Fixes: 8336886f786f ("tcp: TCP Fast Open Server - support TFO listeners")
    Reported-by: syzkaller <syzkaller@googlegroups.com>
    Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
    Link: https://patch.msgid.link/20250915175800.118793-2-kuniyu@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork. [+ + +]
Author: Kuniyuki Iwashima <kuniyu@google.com>
Date:   Tue Sep 9 23:26:12 2025 +0000

    tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.
    
    [ Upstream commit a3967baad4d533dc254c31e0d221e51c8d223d58 ]
    
    syzbot reported the splat below. [0]
    
    The repro does the following:
    
      1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)
      2. Attach the prog to a SOCKMAP
      3. Add a socket to the SOCKMAP
      4. Activate fault injection
      5. Send data less than cork_bytes
    
    At 5., the data is carried over to the next sendmsg() as it is
    smaller than the cork_bytes specified by bpf_msg_cork_bytes().
    
    Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold
    the data, but this fails silently due to fault injection + __GFP_NOWARN.
    
    If the allocation fails, we need to revert the sk->sk_forward_alloc
    change done by sk_msg_alloc().
    
    Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate
    psock->cork.
    
    The "*copied" also needs to be updated such that a proper error can
    be returned to the caller, sendmsg. It fails to allocate psock->cork.
    Nothing has been corked so far, so this patch simply sets "*copied"
    to 0.
    
    [0]:
    WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983
    Modules linked in:
    CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025
    RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156
    Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc
    RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246
    RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80
    RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000
    RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4
    R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380
    R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872
    FS:  00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0
    Call Trace:
     <IRQ>
     __sk_destruct+0x86/0x660 net/core/sock.c:2339
     rcu_do_batch kernel/rcu/tree.c:2605 [inline]
     rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861
     handle_softirqs+0x286/0x870 kernel/softirq.c:579
     __do_softirq kernel/softirq.c:613 [inline]
     invoke_softirq kernel/softirq.c:453 [inline]
     __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680
     irq_exit_rcu+0x9/0x30 kernel/softirq.c:696
     instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]
     sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052
     </IRQ>
    
    Fixes: 4f738adba30a ("bpf: create tcp_bpf_ulp allowing BPF to monitor socket TX/RX data")
    Reported-by: syzbot+4cabd1d2fa917a456db8@syzkaller.appspotmail.com
    Closes: https://lore.kernel.org/netdev/68c0b6b5.050a0220.3c6139.0013.GAE@google.com/
    Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
    Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
    Link: https://patch.msgid.link/20250909232623.4151337-1-kuniyu@google.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
tty: hvc_console: Call hvc_kick in hvc_write unconditionally [+ + +]
Author: Fabian Vogt <fvogt@suse.de>
Date:   Fri Aug 15 13:33:28 2025 +0200

    tty: hvc_console: Call hvc_kick in hvc_write unconditionally
    
    commit cfd956dcb101aa3d25bac321fae923323a47c607 upstream.
    
    After hvc_write completes, call hvc_kick also in the case the output
    buffer has been drained, to ensure tty_wakeup gets called.
    
    This fixes that functions which wait for a drained buffer got stuck
    occasionally.
    
    Cc: stable <stable@kernel.org>
    Closes: https://bugzilla.opensuse.org/show_bug.cgi?id=1230062
    Signed-off-by: Fabian Vogt <fvogt@suse.de>
    Link: https://lore.kernel.org/r/2011735.PYKUYFuaPT@fvogt-thinkpad
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: core: Add 0x prefix to quirks debug output [+ + +]
Author: Jiayi Li <lijiayi@kylinos.cn>
Date:   Tue Jun 3 15:10:45 2025 +0800

    usb: core: Add 0x prefix to quirks debug output
    
    [ Upstream commit 47c428fce0b41b15ab321d8ede871f780ccd038f ]
    
    Use "0x%x" format for quirks debug print to clarify it's a hexadecimal
    value. Improves readability and consistency with other hex outputs.
    
    Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
    Link: https://lore.kernel.org/r/20250603071045.3243699-1-lijiayi@kylinos.cn
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

 
USB: gadget: dummy-hcd: Fix locking bug in RT-enabled kernels [+ + +]
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Wed Sep 17 09:30:03 2025 -0400

    USB: gadget: dummy-hcd: Fix locking bug in RT-enabled kernels
    
    [ Upstream commit 8d63c83d8eb922f6c316320f50c82fa88d099bea ]
    
    Yunseong Kim and the syzbot fuzzer both reported a problem in
    RT-enabled kernels caused by the way dummy-hcd mixes interrupt
    management and spin-locking.  The pattern was:
    
            local_irq_save(flags);
            spin_lock(&dum->lock);
            ...
            spin_unlock(&dum->lock);
            ...             // calls usb_gadget_giveback_request()
            local_irq_restore(flags);
    
    The code was written this way because usb_gadget_giveback_request()
    needs to be called with interrupts disabled and the private lock not
    held.
    
    While this pattern works fine in non-RT kernels, it's not good when RT
    is enabled.  RT kernels handle spinlocks much like mutexes; in particular,
    spin_lock() may sleep.  But sleeping is not allowed while local
    interrupts are disabled.
    
    To fix the problem, rewrite the code to conform to the pattern used
    elsewhere in dummy-hcd and other UDC drivers:
    
            spin_lock_irqsave(&dum->lock, flags);
            ...
            spin_unlock(&dum->lock);
            usb_gadget_giveback_request(...);
            spin_lock(&dum->lock);
            ...
            spin_unlock_irqrestore(&dum->lock, flags);
    
    This approach satisfies the RT requirements.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Cc: stable <stable@kernel.org>
    Fixes: b4dbda1a22d2 ("USB: dummy-hcd: disable interrupts during req->complete")
    Reported-by: Yunseong Kim <ysk@kzalloc.com>
    Closes: <https://lore.kernel.org/linux-usb/5b337389-73b9-4ee4-a83e-7e82bf5af87a@kzalloc.com/>
    Reported-by: syzbot+8baacc4139f12fa77909@syzkaller.appspotmail.com
    Closes: <https://lore.kernel.org/linux-usb/68ac2411.050a0220.37038e.0087.GAE@google.com/>
    Tested-by: syzbot+8baacc4139f12fa77909@syzkaller.appspotmail.com
    CC: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    CC: stable@vger.kernel.org
    Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
    Link: https://lore.kernel.org/r/bb192ae2-4eee-48ee-981f-3efdbbd0d8f0@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: gadget: dummy_hcd: remove usage of list iterator past the loop body [+ + +]
Author: Jakob Koschel <jakobkoschel@gmail.com>
Date:   Wed Sep 17 09:30:02 2025 -0400

    usb: gadget: dummy_hcd: remove usage of list iterator past the loop body
    
    [ Upstream commit 7975f080d3557725160a878b1a64339043ba3d91 ]
    
    To move the list iterator variable into the list_for_each_entry_*()
    macro in the future it should be avoided to use the list iterator
    variable after the loop body.
    
    To *never* use the list iterator variable after the loop it was
    concluded to use a separate iterator variable [1].
    
    Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/
    Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
    Link: https://lore.kernel.org/r/20220308171818.384491-26-jakobkoschel@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Stable-dep-of: 8d63c83d8eb9 ("USB: gadget: dummy-hcd: Fix locking bug in RT-enabled kernels")
    Signed-off-by: Sasha Levin <sashal@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: hub: Fix flushing of delayed work used for post resume purposes [+ + +]
Author: Mathias Nyman <mathias.nyman@linux.intel.com>
Date:   Fri Jun 27 19:43:48 2025 +0300

    usb: hub: Fix flushing of delayed work used for post resume purposes
    
    commit 9bd9c8026341f75f25c53104eb7e656e357ca1a2 upstream.
    
    Delayed work that prevents USB3 hubs from runtime-suspending too early
    needed to be flushed in hub_quiesce() to resolve issues detected on
    QC SC8280XP CRD board during suspend resume testing.
    
    This flushing did however trigger new issues on Raspberry Pi 3B+, which
    doesn't have USB3 ports, and doesn't queue any post resume delayed work.
    
    The flushed 'hub->init_work' item is used for several purposes, and
    is originally initialized with a 'NULL' work function. The work function
    is also changed on the fly, which may contribute to the issue.
    
    Solve this by creating a dedicated delayed work item for post resume work,
    and flush that delayed work in hub_quiesce()
    
    Cc: stable <stable@kernel.org>
    Fixes: a49e1e2e785f ("usb: hub: Fix flushing and scheduling of delayed work that tunes runtime pm")
    Reported-by: Mark Brown <broonie@kernel.org>
    Closes: https://lore.kernel.org/linux-usb/aF5rNp1l0LWITnEB@finisterre.sirena.org.uk
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # SC8280XP CRD
    Tested-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20250627164348.3982628-2-mathias.nyman@linux.intel.com
    [florian: adjust for lack of hub_{get,put} and timer_delete_sync]
    Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
USB: serial: option: add Telit Cinterion FN990A w/audio compositions [+ + +]
Author: Fabio Porcedda <fabio.porcedda@gmail.com>
Date:   Wed Aug 6 14:09:26 2025 +0200

    USB: serial: option: add Telit Cinterion FN990A w/audio compositions
    
    commit cba70aff623b104085ab5613fedd21f6ea19095a upstream.
    
    Add the following Telit Cinterion FN990A w/audio compositions:
    
    0x1077: tty (diag) + adb + rmnet + audio + tty (AT/NMEA) + tty (AT) +
    tty (AT) + tty (AT)
    T:  Bus=01 Lev=01 Prnt=01 Port=09 Cnt=01 Dev#=  8 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=1077 Rev=05.04
    S:  Manufacturer=Telit Wireless Solutions
    S:  Product=FN990
    S:  SerialNumber=67e04c35
    C:  #Ifs=10 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 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=42 Prot=01 Driver=(none)
    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= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio
    I:  If#= 4 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
    E:  Ad=03(O) Atr=0d(Isoc) MxPS=  68 Ivl=1ms
    I:  If#= 5 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
    E:  Ad=84(I) Atr=0d(Isoc) MxPS=  68 Ivl=1ms
    I:  If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=88(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8a(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 9 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8c(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    
    0x1078: tty (diag) + adb + MBIM + audio + tty (AT/NMEA) + tty (AT) +
    tty (AT) + tty (AT)
    T:  Bus=01 Lev=01 Prnt=01 Port=09 Cnt=01 Dev#= 21 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=1078 Rev=05.04
    S:  Manufacturer=Telit Wireless Solutions
    S:  Product=FN990
    S:  SerialNumber=67e04c35
    C:  #Ifs=11 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 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=42 Prot=01 Driver=(none)
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#=10 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8c(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
    E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
    I:  If#= 3 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio
    I:  If#= 5 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
    I:  If#= 6 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
    E:  Ad=84(I) Atr=0d(Isoc) MxPS=  68 Ivl=1ms
    I:  If#= 7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=88(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 9 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8a(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    
    0x1079: RNDIS + tty (diag) + adb + audio + tty (AT/NMEA) + tty (AT) +
    tty (AT) + tty (AT)
    T:  Bus=01 Lev=01 Prnt=01 Port=09 Cnt=01 Dev#= 23 Spd=480 MxCh= 0
    D:  Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=1079 Rev=05.04
    S:  Manufacturer=Telit Wireless Solutions
    S:  Product=FN990
    S:  SerialNumber=67e04c35
    C:  #Ifs=11 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host
    E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host
    E:  Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#=10 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8c(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=20 Driver=snd-usb-audio
    I:  If#= 5 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
    I:  If#= 6 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=20 Driver=snd-usb-audio
    E:  Ad=84(I) Atr=0d(Isoc) MxPS=  68 Ivl=1ms
    I:  If#= 7 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=88(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 9 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8a(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

USB: serial: option: add Telit Cinterion LE910C4-WWX new compositions [+ + +]
Author: Fabio Porcedda <fabio.porcedda@gmail.com>
Date:   Fri Aug 22 11:08:39 2025 +0200

    USB: serial: option: add Telit Cinterion LE910C4-WWX new compositions
    
    commit a5a261bea9bf8444300d1067b4a73bedee5b5227 upstream.
    
    Add the following Telit Cinterion LE910C4-WWX new compositions:
    
    0x1034: tty (AT) + tty (AT) + rmnet
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  8 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=1034 Rev=00.00
    S:  Manufacturer=Telit
    S:  Product=LE910C4-WWX
    S:  SerialNumber=93f617e7
    C:  #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x1036: tty (AT) + tty (AT)
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=1036 Rev=00.00
    S:  Manufacturer=Telit
    S:  Product=LE910C4-WWX
    S:  SerialNumber=93f617e7
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x1037: tty (diag) + tty (Telit custom) + tty (AT) + tty (AT) + rmnet
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 15 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=1037 Rev=00.00
    S:  Manufacturer=Telit
    S:  Product=LE910C4-WWX
    S:  SerialNumber=93f617e7
    C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 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=ff Prot=ff 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= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x1038: tty (Telit custom) + tty (AT) + tty (AT) + rmnet
    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=1bc7 ProdID=1038 Rev=00.00
    S:  Manufacturer=Telit
    S:  Product=LE910C4-WWX
    S:  SerialNumber=93f617e7
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff 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= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x103b: tty (diag) + tty (Telit custom) + tty (AT) + tty (AT)
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=103b Rev=00.00
    S:  Manufacturer=Telit
    S:  Product=LE910C4-WWX
    S:  SerialNumber=93f617e7
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 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=ff Prot=ff 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= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    0x103c: tty (Telit custom) + tty (AT) + tty (AT)
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 11 Spd=480 MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=103c Rev=00.00
    S:  Manufacturer=Telit
    S:  Product=LE910C4-WWX
    S:  SerialNumber=93f617e7
    C:  #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff 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= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=fe Prot=ff Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
wifi: mac80211: fix incorrect type for ret [+ + +]
Author: Liao Yuanhong <liaoyuanhong@vivo.com>
Date:   Mon Aug 25 10:29:11 2025 +0800

    wifi: mac80211: fix incorrect type for ret
    
    [ Upstream commit a33b375ab5b3a9897a0ab76be8258d9f6b748628 ]
    
    The variable ret is declared as a u32 type, but it is assigned a value
    of -EOPNOTSUPP. Since unsigned types cannot correctly represent negative
    values, the type of ret should be changed to int.
    
    Signed-off-by: Liao Yuanhong <liaoyuanhong@vivo.com>
    Link: https://patch.msgid.link/20250825022911.139377-1-liaoyuanhong@vivo.com
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>