Changelog in Linux kernel 6.6.109

 
afs: Fix potential null pointer dereference in afs_put_server [+ + +]
Author: Zhen Ni <[email protected]>
Date:   Tue Sep 23 15:51:04 2025 +0800

    afs: Fix potential null pointer dereference in afs_put_server
    
    commit 9158c6bb245113d4966df9b2ba602197a379412e upstream.
    
    afs_put_server() accessed server->debug_id before the NULL check, which
    could lead to a null pointer dereference. Move the debug_id assignment,
    ensuring we never dereference a NULL server pointer.
    
    Fixes: 2757a4dc1849 ("afs: Fix access after dec in put functions")
    Cc: [email protected]
    Signed-off-by: Zhen Ni <[email protected]>
    Acked-by: David Howells <[email protected]>
    Reviewed-by: Jeffrey Altman <[email protected]>
    Signed-off-by: Christian Brauner <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ALSA: usb-audio: Add DSD support for Comtrue USB Audio device [+ + +]
Author: noble.yang <[email protected]>
Date:   Thu Jul 31 19:06:14 2025 +0800

    ALSA: usb-audio: Add DSD support for Comtrue USB Audio device
    
    [ Upstream commit e9df1755485dd90a89656e8a21ec4d71c909fa30 ]
    
    The vendor Comtrue Inc. (0x2fc6) produces USB audio chipsets like
    the CT7601 which are capable of Native DSD playback.
    
    This patch adds QUIRK_FLAG_DSD_RAW for Comtrue (VID 0x2fc6), which enables
    native DSD playback (DSD_U32_LE) on their USB Audio device. This has been
    verified under Ubuntu 25.04 with JRiver.
    
    Signed-off-by: noble.yang <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Add mixer quirk for Sony DualSense PS5 [+ + +]
Author: Cristian Ciocaltea <[email protected]>
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 <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Add mute TLV for playback volumes on more devices [+ + +]
Author: qaqland <[email protected]>
Date:   Fri Aug 29 14:40:48 2025 +0800

    ALSA: usb-audio: Add mute TLV for playback volumes on more devices
    
    [ Upstream commit 2cbe4ac193ed7172cfd825c0cc46ce4a41be4ba1 ]
    
    Applying the quirk of that, the lowest Playback mixer volume setting
    mutes the audio output, on more devices.
    
    Suggested-by: Cryolitia PukNgae <[email protected]>
    Signed-off-by: qaqland <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Avoid multiple assignments in mixer_quirks [+ + +]
Author: Cristian Ciocaltea <[email protected]>
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 <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Convert comma to semicolon [+ + +]
Author: Chen Ni <[email protected]>
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 <[email protected]>
    Reviewed-by: Cristian Ciocaltea <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Drop unnecessary parentheses in mixer_quirks [+ + +]
Author: Cristian Ciocaltea <[email protected]>
Date:   Mon May 26 17:07:44 2025 +0300

    ALSA: usb-audio: Drop unnecessary parentheses in mixer_quirks
    
    [ Upstream commit c0495cef8b43ad61efbd4019e3573742e0e63c67 ]
    
    Fix multiple 'CHECK: Unnecessary parentheses around ...' reports from
    checkpatch.pl.
    
    Signed-off-by: Cristian Ciocaltea <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Fix block comments in mixer_quirks [+ + +]
Author: Cristian Ciocaltea <[email protected]>
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 <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Fix build with CONFIG_INPUT=n [+ + +]
Author: Takashi Iwai <[email protected]>
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 <[email protected]>
    Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
    Reviewed-by: Cristian Ciocaltea <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: move mixer_quirks' min_mute into common quirk [+ + +]
Author: Cryolitia PukNgae <[email protected]>
Date:   Wed Aug 27 11:29:02 2025 +0800

    ALSA: usb-audio: move mixer_quirks' min_mute into common quirk
    
    [ Upstream commit 2c3ca8cc55a3afc7a4fa99ed8f5f5d05dd2e65b3 ]
    
    We have found more and more devices that have the same problem, that
    the mixer's minimum value is muted. Accroding to pipewire's MR[1]
    and Arch Linux wiki[2], this should be a very common problem in USB
    audio devices. Move the quirk into common quirk,as a preparation of
    more devices' quirk's patch coming on the road[3].
    
    1. https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2514
    2. https://wiki.archlinux.org/index.php?title=PipeWire&oldid=804138#No_sound_from_USB_DAC_until_30%_volume
    3. On the road, in the physical sense. We have been buying ton of
       these devices for testing the problem.
    
    Tested-by: Guoli An <[email protected]>
    Signed-off-by: Cryolitia PukNgae <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Takashi Iwai <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Remove unneeded wmb() in mixer_quirks [+ + +]
Author: Cristian Ciocaltea <[email protected]>
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 <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

ALSA: usb-audio: Simplify NULL comparison in mixer_quirks [+ + +]
Author: Cristian Ciocaltea <[email protected]>
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 <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
arm64: dts: imx8mp: Correct thermal sensor index [+ + +]
Author: Peng Fan <[email protected]>
Date:   Fri Sep 5 11:01:09 2025 +0800

    arm64: dts: imx8mp: Correct thermal sensor index
    
    [ Upstream commit a50342f976d25aace73ff551845ce89406f48f35 ]
    
    The TMU has two temperature measurement sites located on the chip. The
    probe 0 is located inside of the ANAMIX, while the probe 1 is located near
    the ARM core. This has been confirmed by checking with HW design team and
    checking RTL code.
    
    So correct the {cpu,soc}-thermal sensor index.
    
    Fixes: 30cdd62dce6b ("arm64: dts: imx8mp: Add thermal zones support")
    Signed-off-by: Peng Fan <[email protected]>
    Reviewed-by: Frank Li <[email protected]>
    Signed-off-by: Shawn Guo <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
ARM: bcm: Select ARM_GIC_V3 for ARCH_BRCMSTB [+ + +]
Author: Florian Fainelli <[email protected]>
Date:   Fri Jul 26 16:34:14 2024 -0700

    ARM: bcm: Select ARM_GIC_V3 for ARCH_BRCMSTB
    
    commit 2b28fe75c7dbe7ec322e706eed4622964409e21d upstream.
    
    A number of recent Broadcom STB SoCs utilize a GIC-600 interrupt
    controller thus requiring the use of the GICv3 driver.
    
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Florian Fainelli <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

ARM: dts: kirkwood: Fix sound DAI cells for OpenRD clients [+ + +]
Author: Jihed Chaibi <[email protected]>
Date:   Sat Aug 30 22:37:50 2025 +0200

    ARM: dts: kirkwood: Fix sound DAI cells for OpenRD clients
    
    [ Upstream commit 29341c6c18b8ad2a9a4a68a61be7e1272d842f21 ]
    
    A previous commit changed the '#sound-dai-cells' property for the
    kirkwood audio controller from 1 to 0 in the kirkwood.dtsi file,
    but did not update the corresponding 'sound-dai' property in the
    kirkwood-openrd-client.dts file.
    
    This created a mismatch, causing a dtbs_check validation error where
    the dts provides one cell (<&audio0 0>) while the .dtsi expects zero.
    
    Remove the extraneous cell from the 'sound-dai' property to fix the
    schema validation warning and align with the updated binding.
    
    Fixes: e662e70fa419 ("arm: dts: kirkwood: fix error in #sound-dai-cells size")
    Signed-off-by: Jihed Chaibi <[email protected]>
    Reviewed-by: Krzysztof Kozlowski <[email protected]>
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

ARM: dts: socfpga: sodia: Fix mdio bus probe and PHY address [+ + +]
Author: Nobuhiro Iwamatsu <[email protected]>
Date:   Thu Nov 21 16:13:25 2024 +0900

    ARM: dts: socfpga: sodia: Fix mdio bus probe and PHY address
    
    commit ea9da67e2add7bd5f1e4b38dc2404480e711f4d8 upstream.
    
    On SoCFPGA/Sodia board, mdio bus cannot be probed, so the PHY cannot be
    found and the network device does not work.
    
    ```
    stmmaceth ff702000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
    ```
    
    To probe the mdio bus, add "snps,dwmac-mdio" as compatible string of the
    mdio bus. Also the PHY address connected to this board is 4. Therefore,
    change to 4.
    
    Cc: [email protected] # 6.3+
    Signed-off-by: Nobuhiro Iwamatsu <[email protected]>
    Signed-off-by: Dinh Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Mon Aug 25 11:10:20 2025 -0400

    Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync
    
    [ Upstream commit 9e622804d57e2d08f0271200606bd1270f75126f ]
    
    This fixes the following UFA in hci_acl_create_conn_sync where a
    connection still pending is command submission (conn->state == BT_OPEN)
    maybe freed, also since this also can happen with the likes of
    hci_le_create_conn_sync fix it as well:
    
    BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
    Write of size 2 at addr ffff88805ffcc038 by task kworker/u11:2/9541
    
    CPU: 1 UID: 0 PID: 9541 Comm: kworker/u11:2 Not tainted 6.16.0-rc7 #3 PREEMPT(full)
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
    Workqueue: hci3 hci_cmd_sync_work
    Call Trace:
     <TASK>
     dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
     print_address_description mm/kasan/report.c:378 [inline]
     print_report+0xca/0x230 mm/kasan/report.c:480
     kasan_report+0x118/0x150 mm/kasan/report.c:593
     hci_acl_create_conn_sync+0x5ef/0x790 net/bluetooth/hci_sync.c:6861
     hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332
     process_one_work kernel/workqueue.c:3238 [inline]
     process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
     worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
     kthread+0x70e/0x8a0 kernel/kthread.c:464
     ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
     ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
     </TASK>
    
    Allocated by task 123736:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
     poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
     __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394
     kasan_kmalloc include/linux/kasan.h:260 [inline]
     __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359
     kmalloc_noprof include/linux/slab.h:905 [inline]
     kzalloc_noprof include/linux/slab.h:1039 [inline]
     __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939
     hci_conn_add_unset net/bluetooth/hci_conn.c:1051 [inline]
     hci_connect_acl+0x16c/0x4e0 net/bluetooth/hci_conn.c:1634
     pair_device+0x418/0xa70 net/bluetooth/mgmt.c:3556
     hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719
     hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839
     sock_sendmsg_nosec net/socket.c:712 [inline]
     __sock_sendmsg+0x219/0x270 net/socket.c:727
     sock_write_iter+0x258/0x330 net/socket.c:1131
     new_sync_write fs/read_write.c:593 [inline]
     vfs_write+0x54b/0xa90 fs/read_write.c:686
     ksys_write+0x145/0x250 fs/read_write.c:738
     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
    
    Freed by task 103680:
     kasan_save_stack mm/kasan/common.c:47 [inline]
     kasan_save_track+0x3e/0x80 mm/kasan/common.c:68
     kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576
     poison_slab_object mm/kasan/common.c:247 [inline]
     __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264
     kasan_slab_free include/linux/kasan.h:233 [inline]
     slab_free_hook mm/slub.c:2381 [inline]
     slab_free mm/slub.c:4643 [inline]
     kfree+0x18e/0x440 mm/slub.c:4842
     device_release+0x9c/0x1c0
     kobject_cleanup lib/kobject.c:689 [inline]
     kobject_release lib/kobject.c:720 [inline]
     kref_put include/linux/kref.h:65 [inline]
     kobject_put+0x22b/0x480 lib/kobject.c:737
     hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline]
     hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173
     hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
     hci_event_func net/bluetooth/hci_event.c:7477 [inline]
     hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
     hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
     process_one_work kernel/workqueue.c:3238 [inline]
     process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
     worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
     kthread+0x70e/0x8a0 kernel/kthread.c:464
     ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
     ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
    
    Last potentially related work creation:
     kasan_save_stack+0x3e/0x60 mm/kasan/common.c:47
     kasan_record_aux_stack+0xbd/0xd0 mm/kasan/generic.c:548
     insert_work+0x3d/0x330 kernel/workqueue.c:2183
     __queue_work+0xbd9/0xfe0 kernel/workqueue.c:2345
     queue_delayed_work_on+0x18b/0x280 kernel/workqueue.c:2561
     pairing_complete+0x1e7/0x2b0 net/bluetooth/mgmt.c:3451
     pairing_complete_cb+0x1ac/0x230 net/bluetooth/mgmt.c:3487
     hci_connect_cfm include/net/bluetooth/hci_core.h:2064 [inline]
     hci_conn_failed+0x24d/0x310 net/bluetooth/hci_conn.c:1275
     hci_conn_complete_evt+0x3c7/0x1040 net/bluetooth/hci_event.c:3199
     hci_event_func net/bluetooth/hci_event.c:7477 [inline]
     hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531
     hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070
     process_one_work kernel/workqueue.c:3238 [inline]
     process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321
     worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402
     kthread+0x70e/0x8a0 kernel/kthread.c:464
     ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
     ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245
    
    Fixes: aef2aa4fa98e ("Bluetooth: hci_event: Fix creating hci_conn object on error status")
    Reported-by: Junvyyang, Tencent Zhuque Lab <[email protected]>
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

Bluetooth: hci_sync: Fix hci_resume_advertising_sync [+ + +]
Author: Luiz Augusto von Dentz <[email protected]>
Date:   Fri Sep 5 10:29:18 2025 -0400

    Bluetooth: hci_sync: Fix hci_resume_advertising_sync
    
    [ Upstream commit 1488af7b8b5f9896ea88ee35aa3301713f72737c ]
    
    hci_resume_advertising_sync is suppose to resume all instance paused by
    hci_pause_advertising_sync, this logic is used for procedures are only
    allowed when not advertising, but instance 0x00 was not being
    re-enabled.
    
    Fixes: ad383c2c65a5 ("Bluetooth: hci_sync: Enable advertising when LL privacy is enabled")
    Signed-off-by: Luiz Augusto von Dentz <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bnxt_en: correct offset handling for IPv6 destination address [+ + +]
Author: Alok Tiwari <[email protected]>
Date:   Sat Sep 20 05:11:17 2025 -0700

    bnxt_en: correct offset handling for IPv6 destination address
    
    [ Upstream commit 3d3aa9472c6dd0704e9961ed4769caac5b1c8d52 ]
    
    In bnxt_tc_parse_pedit(), the code incorrectly writes IPv6
    destination values to the source address field (saddr) when
    processing pedit offsets within the destination address range.
    
    This patch corrects the assignment to use daddr instead of saddr,
    ensuring that pedit operations on IPv6 destination addresses are
    applied correctly.
    
    Fixes: 9b9eb518e338 ("bnxt_en: Add support for NAT(L3/L4 rewrite)")
    Signed-off-by: Alok Tiwari <[email protected]>
    Reviewed-by: Somnath Kotur <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
bpf: Reject bpf_timer for PREEMPT_RT [+ + +]
Author: Leon Hwang <[email protected]>
Date:   Wed Sep 10 20:57:39 2025 +0800

    bpf: Reject bpf_timer for PREEMPT_RT
    
    [ Upstream commit e25ddfb388c8b7e5f20e3bf38d627fb485003781 ]
    
    When enable CONFIG_PREEMPT_RT, the kernel will warn when run timer
    selftests by './test_progs -t timer':
    
    BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
    
    In order to avoid such warning, reject bpf_timer in verifier when
    PREEMPT_RT is enabled.
    
    Signed-off-by: Leon Hwang <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow [+ + +]
Author: Vincent Mailhol <[email protected]>
Date:   Thu Sep 18 18:00:24 2025 +0900

    can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow
    
    [ Upstream commit 38c0abad45b190a30d8284a37264d2127a6ec303 ]
    
    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 etas_es58x 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, es58x_start_xmit() receives a CAN XL frame which it is not
    able to correctly handle and will thus misinterpret it as a CAN(FD)
    frame.
    
    This can result in a buffer overflow. For example, using the es581.4
    variant, the frame will be dispatched to es581_4_tx_can_msg(), go
    through the last check at the beginning of this function:
    
            if (can_is_canfd_skb(skb))
                    return -EMSGSIZE;
    
    and reach this line:
    
            memcpy(tx_can_msg->data, cf->data, 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!
    
    Populate net_device_ops->ndo_change_mtu() to ensure that the
    interface's MTU can not be set to anything bigger than CAN_MTU or
    CANFD_MTU (depending on the device capabilities). By fixing the root
    cause, this prevents the buffer overflow.
    
    Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces")
    Signed-off-by: Vincent Mailhol <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: hi311x: populate ndo_change_mtu() to prevent buffer overflow [+ + +]
Author: Vincent Mailhol <[email protected]>
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 <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: mcba_usb: populate ndo_change_mtu() to prevent buffer overflow [+ + +]
Author: Vincent Mailhol <[email protected]>
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 <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: peak_usb: fix shift-out-of-bounds issue [+ + +]
Author: Stéphane Grosjean <[email protected]>
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 <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Reported-by: Marc Kleine-Budde <[email protected]>
    Closes: https://lore.kernel.org/[email protected]
    Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core")
    [mkl: update subject, apply manually]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: rcar_can: rcar_can_resume(): fix s2ram with PSCI [+ + +]
Author: Geert Uytterhoeven <[email protected]>
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 <[email protected]>
    Link: https://patch.msgid.link/699b2f7fcb60b31b6f976a37f08ce99c5ffccb31.1755165227.git.geert+renesas@glider.be
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

can: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow [+ + +]
Author: Vincent Mailhol <[email protected]>
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 <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Marc Kleine-Budde <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
cpufreq: Initialize cpufreq-based invariance before subsys [+ + +]
Author: Christian Loehle <[email protected]>
Date:   Thu Sep 18 11:15:52 2025 +0100

    cpufreq: Initialize cpufreq-based invariance before subsys
    
    [ Upstream commit 8ffe28b4e8d8b18cb2f2933410322c24f039d5d6 ]
    
    commit 2a6c72738706 ("cpufreq: Initialize cpufreq-based
    frequency-invariance later") postponed the frequency invariance
    initialization to avoid disabling it in the error case.
    This isn't locking safe, instead move the initialization up before
    the subsys interface is registered (which will rebuild the
    sched_domains) and add the corresponding disable on the error path.
    
    Observed lockdep without this patch:
    [    0.989686] ======================================================
    [    0.989688] WARNING: possible circular locking dependency detected
    [    0.989690] 6.17.0-rc4-cix-build+ #31 Tainted: G S
    [    0.989691] ------------------------------------------------------
    [    0.989692] swapper/0/1 is trying to acquire lock:
    [    0.989693] ffff800082ada7f8 (sched_energy_mutex){+.+.}-{4:4}, at: rebuild_sched_domains_energy+0x30/0x58
    [    0.989705]
                   but task is already holding lock:
    [    0.989706] ffff000088c89bc8 (&policy->rwsem){+.+.}-{4:4}, at: cpufreq_online+0x7f8/0xbe0
    [    0.989713]
                   which lock already depends on the new lock.
    
    Fixes: 2a6c72738706 ("cpufreq: Initialize cpufreq-based frequency-invariance later")
    Signed-off-by: Christian Loehle <[email protected]>
    Signed-off-by: Rafael J. Wysocki <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
crypto: af_alg - Fix incorrect boolean values in af_alg_ctx [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Wed Sep 24 13:18:22 2025 -0700

    crypto: af_alg - Fix incorrect boolean values in af_alg_ctx
    
    commit d0ca0df179c4b21e2a6c4a4fb637aa8fa14575cb upstream.
    
    Commit 1b34cbbf4f01 ("crypto: af_alg - Disallow concurrent writes in
    af_alg_sendmsg") changed some fields from bool to 1-bit bitfields of
    type u32.
    
    However, some assignments to these fields, specifically 'more' and
    'merge', assign values greater than 1.  These relied on C's implicit
    conversion to bool, such that zero becomes false and nonzero becomes
    true.
    
    With a 1-bit bitfields of type u32 instead, mod 2 of the value is taken
    instead, resulting in 0 being assigned in some cases when 1 was intended.
    
    Fix this by restoring the bool type.
    
    Fixes: 1b34cbbf4f01 ("crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg")
    Cc: [email protected]
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/ast: Use msleep instead of mdelay for edid read [+ + +]
Author: Nirmoy Das <[email protected]>
Date:   Mon Sep 29 11:50:10 2025 -0400

    drm/ast: Use msleep instead of mdelay for edid read
    
    [ Upstream commit c7c31f8dc54aa3c9b2c994b5f1ff7e740a654e97 ]
    
    The busy-waiting in `mdelay()` can cause CPU stalls and kernel timeouts
    during boot.
    
    Signed-off-by: Nirmoy Das <[email protected]>
    Reviewed-by: Thomas Zimmermann <[email protected]>
    Tested-by: Carol L Soto [email protected]<mailto:[email protected]>
    Fixes: 594e9c04b586 ("drm/ast: Create the driver for ASPEED proprietory Display-Port")
    Cc: KuoHsiang Chou <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Cc: Dave Airlie <[email protected]>
    Cc: Jocelyn Falempe <[email protected]>
    Cc: [email protected]
    Cc: <[email protected]> # v5.19+
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    [ Applied change to ast_astdp_read_edid() instead of ast_astdp_read_edid_block() ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
drm/gma500: Fix null dereference in hdmi teardown [+ + +]
Author: Zabelin Nikita <[email protected]>
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 <[email protected]>
    Signed-off-by: Patrik Jakobsson <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Sasha Levin <[email protected]>

 
drm/i915/backlight: Return immediately when scale() finds invalid parameters [+ + +]
Author: Guenter Roeck <[email protected]>
Date:   Tue Jan 21 06:52:03 2025 -0800

    drm/i915/backlight: Return immediately when scale() finds invalid parameters
    
    commit 6f71507415841d1a6d38118e5fa0eaf0caab9c17 upstream.
    
    The scale() functions detects invalid parameters, but continues
    its calculations anyway. This causes bad results if negative values
    are used for unsigned operations. Worst case, a division by 0 error
    will be seen if source_min == source_max.
    
    On top of that, after v6.13, the sequence of WARN_ON() followed by clamp()
    may result in a build error with gcc 13.x.
    
    drivers/gpu/drm/i915/display/intel_backlight.c: In function 'scale':
    include/linux/compiler_types.h:542:45: error:
            call to '__compiletime_assert_415' declared with attribute error:
            clamp() low limit source_min greater than high limit source_max
    
    This happens if the compiler decides to rearrange the code as follows.
    
            if (source_min > source_max) {
                    WARN(..);
                    /* Do the clamp() knowing that source_min > source_max */
                    source_val = clamp(source_val, source_min, source_max);
            } else {
                    /* Do the clamp knowing that source_min <= source_max */
                    source_val = clamp(source_val, source_min, source_max);
            }
    
    Fix the problem by evaluating the return values from WARN_ON and returning
    immediately after a warning. While at it, fix divide by zero error seen
    if source_min == source_max.
    
    Analyzed-by: Linus Torvalds <[email protected]>
    Suggested-by: Linus Torvalds <[email protected]>
    Suggested-by: David Laight <[email protected]>
    Cc: David Laight <[email protected]>
    Cc: Jani Nikula <[email protected]>
    Cc: Andy Shevchenko <[email protected]>
    Signed-off-by: Guenter Roeck <[email protected]>
    Reviewed-by: Rodrigo Vivi <[email protected]>
    Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
    Signed-off-by: Rodrigo Vivi <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
ethernet: rvu-af: Remove slash from the driver name [+ + +]
Author: Petr Malat <[email protected]>
Date:   Thu Sep 18 17:21:07 2025 +0200

    ethernet: rvu-af: Remove slash from the driver name
    
    [ Upstream commit b65678cacc030efd53c38c089fb9b741a2ee34c8 ]
    
    Having a slash in the driver name leads to EIO being returned while
    reading /sys/module/rvu_af/drivers content.
    
    Remove DRV_STRING as it's not used anywhere.
    
    Fixes: 91c6945ea1f9 ("octeontx2-af: cn10k: Add RPM MAC support")
    Signed-off-by: Petr Malat <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
fbcon: fix integer overflow in fbcon_do_set_font [+ + +]
Author: Samasth Norway Ananda <[email protected]>
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 <[email protected]>
    Reviewed-by: Thomas Zimmermann <[email protected]>
    Fixes: 39b3cffb8cf3 ("fbcon: prevent user font height or width change from causing potential out-of-bounds access")
    Cc: George Kennedy <[email protected]>
    Cc: stable <[email protected]>
    Cc: [email protected]
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Simona Vetter <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Cc: "Ville Syrjälä" <[email protected]>
    Cc: Sam Ravnborg <[email protected]>
    Cc: Qianqiang Liu <[email protected]>
    Cc: Shixiong Ou <[email protected]>
    Cc: Kees Cook <[email protected]>
    Cc: <[email protected]> # v5.9+
    Signed-off-by: Thomas Zimmermann <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

fbcon: Fix OOB access in font allocation [+ + +]
Author: Thomas Zimmermann <[email protected]>
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 <[email protected]>
    Fixes: 1a194e6c8e1e ("fbcon: fix integer overflow in fbcon_do_set_font")
    Reported-by: Jani Nikula <[email protected]>
    Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15020
    Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6201
    Cc: Samasth Norway Ananda <[email protected]>
    Cc: Thomas Zimmermann <[email protected]>
    Cc: George Kennedy <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Simona Vetter <[email protected]>
    Cc: Helge Deller <[email protected]>
    Cc: "Ville Syrjälä" <[email protected]>
    Cc: Sam Ravnborg <[email protected]>
    Cc: Qianqiang Liu <[email protected]>
    Cc: Shixiong Ou <[email protected]>
    Cc: Kees Cook <[email protected]>
    Cc: <[email protected]> # v5.9+
    Cc: Zsolt Kajtar <[email protected]>
    Reviewed-by: Lucas De Marchi <[email protected]>
    Reviewed-by: Qianqiang Liu <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
firewire: core: fix overlooked update of subsystem ABI version [+ + +]
Author: Takashi Sakamoto <[email protected]>
Date:   Sat Sep 20 11:51:48 2025 +0900

    firewire: core: fix overlooked update of subsystem ABI version
    
    [ Upstream commit 853a57ba263adfecf4430b936d6862bc475b4bb5 ]
    
    In kernel v6.5, several functions were added to the cdev layer. This
    required updating the default version of subsystem ABI up to 6, but
    this requirement was overlooked.
    
    This commit updates the version accordingly.
    
    Fixes: 6add87e9764d ("firewire: cdev: add new version of ABI to notify time stamp at request/response subaction of transaction#")
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Takashi Sakamoto <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
futex: Prevent use-after-free during requeue-PI [+ + +]
Author: Sebastian Andrzej Siewior <[email protected]>
Date:   Wed Sep 10 12:42:43 2025 +0200

    futex: Prevent use-after-free during requeue-PI
    
    [ Upstream commit b549113738e8c751b613118032a724b772aa83f2 ]
    
    syzbot managed to trigger the following race:
    
       T1                               T2
    
     futex_wait_requeue_pi()
       futex_do_wait()
         schedule()
                                   futex_requeue()
                                     futex_proxy_trylock_atomic()
                                       futex_requeue_pi_prepare()
                                       requeue_pi_wake_futex()
                                         futex_requeue_pi_complete()
                                          /* preempt */
    
             * timeout/ signal wakes T1 *
    
       futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED
       futex_hash_put()
      // back to userland, on stack futex_q is garbage
    
                                          /* back */
                                         wake_up_state(q->task, TASK_NORMAL);
    
    In this scenario futex_wait_requeue_pi() is able to leave without using
    futex_q::lock_ptr for synchronization.
    
    This can be prevented by reading futex_q::task before updating the
    futex_q::requeue_state. A reference on the task_struct is not needed
    because requeue_pi_wake_futex() is invoked with a spinlock_t held which
    implies a RCU read section.
    
    Even if T1 terminates immediately after, the task_struct will remain valid
    during T2's wake_up_state().  A READ_ONCE on futex_q::task before
    futex_requeue_pi_complete() is enough because it ensures that the variable
    is read before the state is updated.
    
    Read futex_q::task before updating the requeue state, use it for the
    following wakeup.
    
    Fixes: 07d91ef510fb1 ("futex: Prevent requeue_pi() lock nesting issue on RT")
    Reported-by: [email protected]
    Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Sasha Levin <[email protected]>

 
gpiolib: Extend software-node support to support secondary software-nodes [+ + +]
Author: Hans de Goede <[email protected]>
Date:   Mon Sep 29 14:57:56 2025 -0400

    gpiolib: Extend software-node support to support secondary software-nodes
    
    [ Upstream commit c6ccc4dde17676dfe617b9a37bd9ba19a8fc87ee ]
    
    When a software-node gets added to a device which already has another
    fwnode as primary node it will become the secondary fwnode for that
    device.
    
    Currently if a software-node with GPIO properties ends up as the secondary
    fwnode then gpiod_find_by_fwnode() will fail to find the GPIOs.
    
    Add a new gpiod_fwnode_lookup() helper which falls back to calling
    gpiod_find_by_fwnode() with the secondary fwnode if the GPIO was not
    found in the primary fwnode.
    
    Fixes: e7f9ff5dc90c ("gpiolib: add support for software nodes")
    Cc: [email protected]
    Signed-off-by: Hans de Goede <[email protected]>
    Reviewed-by: Dmitry Torokhov <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Bartosz Golaszewski <[email protected]>
    [ Adjust context ]
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
HID: asus: add support for missing PX series fn keys [+ + +]
Author: Amit Chaudhari <[email protected]>
Date:   Tue Aug 19 17:49:19 2025 -0400

    HID: asus: add support for missing PX series fn keys
    
    commit 831f70a5b93bd2d9e858ced2c12fab5766ede5e7 upstream.
    
    Add support for missing hotkey keycodes affecting Asus PX13 and PX16 families
    so userspace can use them.
    
    Signed-off-by: Amit Chaudhari <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
i2c: designware: Add quirk for Intel Xe [+ + +]
Author: Heikki Krogerus <[email protected]>
Date:   Tue Jul 1 15:22:49 2025 +0300

    i2c: designware: Add quirk for Intel Xe
    
    [ Upstream commit f6a8e9f3de4567c71ef9f5f13719df69a8b96081 ]
    
    The regmap is coming from the parent also in case of Xe
    GPUs. Reusing the Wangxun quirk for that.
    
    Acked-by: Jarkko Nikula <[email protected]>
    Co-developed-by: Michael J. Ruhl <[email protected]>
    Signed-off-by: Michael J. Ruhl <[email protected]>
    Signed-off-by: Heikki Krogerus <[email protected]>
    Reviewed-by: Andi Shyti <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Rodrigo Vivi <[email protected]>
    [Rodrigo fixed the co-developed tags while merging]
    Signed-off-by: Sasha Levin <[email protected]>

 
i40e: add mask to apply valid bits for itr_idx [+ + +]
Author: Lukasz Czapnik <[email protected]>
Date:   Wed Aug 13 12:45:17 2025 +0200

    i40e: add mask to apply valid bits for itr_idx
    
    commit eac04428abe9f9cb203ffae4600791ea1d24eb18 upstream.
    
    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: [email protected]
    Signed-off-by: Lukasz Czapnik <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Signed-off-by: Przemek Kitszel <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i40e: add max boundary check for VF filters [+ + +]
Author: Lukasz Czapnik <[email protected]>
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: [email protected]
    Signed-off-by: Lukasz Czapnik <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Signed-off-by: Przemek Kitszel <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i40e: add validation for ring_len param [+ + +]
Author: Lukasz Czapnik <[email protected]>
Date:   Mon Sep 29 10:11:10 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: [email protected]
    Signed-off-by: Lukasz Czapnik <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Signed-off-by: Przemek Kitszel <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i40e: fix idx validation in config queues msg [+ + +]
Author: Lukasz Czapnik <[email protected]>
Date:   Wed Aug 13 12:45:13 2025 +0200

    i40e: fix idx validation in config queues msg
    
    commit f1ad24c5abe1eaef69158bac1405a74b3c365115 upstream.
    
    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: [email protected]
    Signed-off-by: Lukasz Czapnik <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Signed-off-by: Przemek Kitszel <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Kamakshi Nellore <[email protected]> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i40e: fix idx validation in i40e_validate_queue_map [+ + +]
Author: Lukasz Czapnik <[email protected]>
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: [email protected]
    Signed-off-by: Lukasz Czapnik <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Signed-off-by: Przemek Kitszel <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Kamakshi Nellore <[email protected]> (A Contingent Worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i40e: fix input validation logic for action_meta [+ + +]
Author: Lukasz Czapnik <[email protected]>
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: [email protected]
    Signed-off-by: Lukasz Czapnik <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Signed-off-by: Przemek Kitszel <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i40e: fix validation of VF state in get resources [+ + +]
Author: Lukasz Czapnik <[email protected]>
Date:   Wed Aug 13 12:45:15 2025 +0200

    i40e: fix validation of VF state in get resources
    
    commit 877b7e6ffc23766448236e8732254534c518ba42 upstream.
    
    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: [email protected]
    Signed-off-by: Lukasz Czapnik <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Signed-off-by: Przemek Kitszel <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i40e: improve VF MAC filters accounting [+ + +]
Author: Lukasz Czapnik <[email protected]>
Date:   Wed Aug 13 12:45:18 2025 +0200

    i40e: improve VF MAC filters accounting
    
    commit b99dd77076bd3fddac6f7f1cbfa081c38fde17f5 upstream.
    
    When adding new VM MAC, driver checks only *active* filters in
    vsi->mac_filter_hash. Each MAC, even in non-active state is using resources.
    
    To determine number of MACs VM uses, count VSI filters in *any* state.
    
    Add i40e_count_all_filters() to simply count all filters, and rename
    i40e_count_filters() to i40e_count_active_filters() to avoid ambiguity.
    
    Fixes: cfb1d572c986 ("i40e: Add ensurance of MacVlan resources for every trusted VF")
    Cc: [email protected]
    Signed-off-by: Lukasz Czapnik <[email protected]>
    Reviewed-by: Aleksandr Loktionov <[email protected]>
    Signed-off-by: Przemek Kitszel <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Tested-by: Rafal Romanowski <[email protected]>
    Signed-off-by: Tony Nguyen <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

i40e: increase max descriptors for XL710 [+ + +]
Author: Justin Bronder <[email protected]>
Date:   Mon Sep 29 10:11:09 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 <[email protected]>
    Reviewed-by: Jacob Keller <[email protected]>
    Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel)
    Signed-off-by: Tony Nguyen <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: 55d225670def ("i40e: add validation for ring_len param")
    Signed-off-by: Sasha Levin <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
IB/mlx5: Fix obj_type mismatch for SRQ event subscriptions [+ + +]
Author: Or Har-Toov <[email protected]>
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 <[email protected]>
    Reviewed-by: Edward Srouji <[email protected]>
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
kmsan: fix out-of-bounds access to shadow memory [+ + +]
Author: Eric Biggers <[email protected]>
Date:   Thu Sep 11 12:58:58 2025 -0700

    kmsan: fix out-of-bounds access to shadow memory
    
    commit 85e1ff61060a765d91ee62dc5606d4d547d9d105 upstream.
    
    Running sha224_kunit on a KMSAN-enabled kernel results in a crash in
    kmsan_internal_set_shadow_origin():
    
        BUG: unable to handle page fault for address: ffffbc3840291000
        #PF: supervisor read access in kernel mode
        #PF: error_code(0x0000) - not-present page
        PGD 1810067 P4D 1810067 PUD 192d067 PMD 3c17067 PTE 0
        Oops: 0000 [#1] SMP NOPTI
        CPU: 0 UID: 0 PID: 81 Comm: kunit_try_catch Tainted: G                 N  6.17.0-rc3 #10 PREEMPT(voluntary)
        Tainted: [N]=TEST
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
        RIP: 0010:kmsan_internal_set_shadow_origin+0x91/0x100
        [...]
        Call Trace:
        <TASK>
        __msan_memset+0xee/0x1a0
        sha224_final+0x9e/0x350
        test_hash_buffer_overruns+0x46f/0x5f0
        ? kmsan_get_shadow_origin_ptr+0x46/0xa0
        ? __pfx_test_hash_buffer_overruns+0x10/0x10
        kunit_try_run_case+0x198/0xa00
    
    This occurs when memset() is called on a buffer that is not 4-byte aligned
    and extends to the end of a guard page, i.e.  the next page is unmapped.
    
    The bug is that the loop at the end of kmsan_internal_set_shadow_origin()
    accesses the wrong shadow memory bytes when the address is not 4-byte
    aligned.  Since each 4 bytes are associated with an origin, it rounds the
    address and size so that it can access all the origins that contain the
    buffer.  However, when it checks the corresponding shadow bytes for a
    particular origin, it incorrectly uses the original unrounded shadow
    address.  This results in reads from shadow memory beyond the end of the
    buffer's shadow memory, which crashes when that memory is not mapped.
    
    To fix this, correctly align the shadow address before accessing the 4
    shadow bytes corresponding to each origin.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 2ef3cec44c60 ("kmsan: do not wipe out origin when doing partial unpoisoning")
    Signed-off-by: Eric Biggers <[email protected]>
    Tested-by: Alexander Potapenko <[email protected]>
    Reviewed-by: Alexander Potapenko <[email protected]>
    Cc: Dmitriy Vyukov <[email protected]>
    Cc: Marco Elver <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
Linux: Linux 6.6.109 [+ + +]
Author: Greg Kroah-Hartman <[email protected]>
Date:   Thu Oct 2 13:42:57 2025 +0200

    Linux 6.6.109
    
    Link: https://lore.kernel.org/r/[email protected]
    Tested-by: Florian Fainelli <[email protected]>
    Tested-by: Brett A C Sheffield <[email protected]>
    Tested-by: Peter Schneider <[email protected]>
    Tested-by: Ron Economos <[email protected]>
    Tested-by: Jon Hunter <[email protected]>
    Tested-by: Mark Brown <[email protected]>
    Tested-by: Linux Kernel Functional Testing <[email protected]>
    Tested-by: Shuah Khan <[email protected]>
    Tested-by: Miguel Ojeda <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
loop: Avoid updating block size under exclusive owner [+ + +]
Author: Jan Kara <[email protected]>
Date:   Fri Jul 11 18:32:03 2025 +0200

    loop: Avoid updating block size under exclusive owner
    
    commit 7e49538288e523427beedd26993d446afef1a6fb upstream.
    
    Syzbot came up with a reproducer where a loop device block size is
    changed underneath a mounted filesystem. This causes a mismatch between
    the block device block size and the block size stored in the superblock
    causing confusion in various places such as fs/buffer.c. The particular
    issue triggered by syzbot was a warning in __getblk_slow() due to
    requested buffer size not matching block device block size.
    
    Fix the problem by getting exclusive hold of the loop device to change
    its block size. This fails if somebody (such as filesystem) has already
    an exclusive ownership of the block device and thus prevents modifying
    the loop device under some exclusive owner which doesn't expect it.
    
    Reported-by: [email protected]
    Signed-off-by: Jan Kara <[email protected]>
    Tested-by: [email protected]
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jens Axboe <[email protected]>
    Signed-off-by: Zheng Qixing <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
minmax.h: add whitespace around operators and after commas [+ + +]
Author: David Laight <[email protected]>
Date:   Mon Sep 29 17:17:27 2025 +0000

    minmax.h: add whitespace around operators and after commas
    
    [ Upstream commit 71ee9b16251ea4bf7c1fe222517c82bdb3220acc ]
    
    Patch series "minmax.h: Cleanups and minor optimisations".
    
    Some tidyups and minor changes to minmax.h.
    
    This patch (of 7):
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: David Laight <[email protected]>
    Cc: Andy Shevchenko <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Dan Carpenter <[email protected]>
    Cc: Jason A. Donenfeld <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Cc: Mateusz Guzik <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Pedro Falcato <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

minmax.h: move all the clamp() definitions after the min/max() ones [+ + +]
Author: David Laight <[email protected]>
Date:   Mon Sep 29 17:17:31 2025 +0000

    minmax.h: move all the clamp() definitions after the min/max() ones
    
    [ Upstream commit c3939872ee4a6b8bdcd0e813c66823b31e6e26f7 ]
    
    At some point the definitions for clamp() got added in the middle of the
    ones for min() and max().  Re-order the definitions so they are more
    sensibly grouped.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: David Laight <[email protected]>
    Cc: Andy Shevchenko <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Dan Carpenter <[email protected]>
    Cc: Jason A. Donenfeld <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Cc: Mateusz Guzik <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Pedro Falcato <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

minmax.h: reduce the #define expansion of min(), max() and clamp() [+ + +]
Author: David Laight <[email protected]>
Date:   Mon Sep 29 17:17:29 2025 +0000

    minmax.h: reduce the #define expansion of min(), max() and clamp()
    
    [ Upstream commit b280bb27a9f7c91ddab730e1ad91a9c18a051f41 ]
    
    Since the test for signed values being non-negative only relies on
    __builtion_constant_p() (not is_constexpr()) it can use the 'ux' variable
    instead of the caller supplied expression.  This means that the #define
    parameters are only expanded twice.  Once in the code and once quoted in
    the error message.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: David Laight <[email protected]>
    Cc: Andy Shevchenko <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Dan Carpenter <[email protected]>
    Cc: Jason A. Donenfeld <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Cc: Mateusz Guzik <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Pedro Falcato <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

minmax.h: remove some #defines that are only expanded once [+ + +]
Author: David Laight <[email protected]>
Date:   Mon Sep 29 17:17:33 2025 +0000

    minmax.h: remove some #defines that are only expanded once
    
    [ Upstream commit 2b97aaf74ed534fb838d09867d09a3ca5d795208 ]
    
    The bodies of __signed_type_use() and __unsigned_type_use() are much the
    same size as their names - so put the bodies in the only line that expands
    them.
    
    Similarly __signed_type() is defined separately for 64bit and then used
    exactly once just below.
    
    Change the test for __signed_type from CONFIG_64BIT to one based on gcc
    defined macros so that the code is valid if it gets used outside of a
    kernel build.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: David Laight <[email protected]>
    Cc: Andy Shevchenko <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Dan Carpenter <[email protected]>
    Cc: Jason A. Donenfeld <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Cc: Mateusz Guzik <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Pedro Falcato <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

minmax.h: simplify the variants of clamp() [+ + +]
Author: David Laight <[email protected]>
Date:   Mon Sep 29 17:17:32 2025 +0000

    minmax.h: simplify the variants of clamp()
    
    [ Upstream commit 495bba17cdf95e9703af1b8ef773c55ef0dfe703 ]
    
    Always pass a 'type' through to __clamp_once(), pass '__auto_type' from
    clamp() itself.
    
    The expansion of __types_ok3() is reasonable so it isn't worth the added
    complexity of avoiding it when a fixed type is used for all three values.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: David Laight <[email protected]>
    Cc: Andy Shevchenko <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Dan Carpenter <[email protected]>
    Cc: Jason A. Donenfeld <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Cc: Mateusz Guzik <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Pedro Falcato <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

minmax.h: update some comments [+ + +]
Author: David Laight <[email protected]>
Date:   Mon Sep 29 17:17:28 2025 +0000

    minmax.h: update some comments
    
    [ Upstream commit 10666e99204818ef45c702469488353b5bb09ec7 ]
    
    - Change three to several.
    - Remove the comment about retaining constant expressions, no longer true.
    - Realign to nearer 80 columns and break on major punctiation.
    - Add a leading comment to the block before __signed_type() and __is_nonneg()
      Otherwise the block explaining the cast is a bit 'floating'.
      Reword the rest of that comment to improve readability.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: David Laight <[email protected]>
    Cc: Andy Shevchenko <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Dan Carpenter <[email protected]>
    Cc: Jason A. Donenfeld <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Cc: Mateusz Guzik <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Pedro Falcato <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp() [+ + +]
Author: David Laight <[email protected]>
Date:   Mon Sep 29 17:17:30 2025 +0000

    minmax.h: use BUILD_BUG_ON_MSG() for the lo < hi test in clamp()
    
    [ Upstream commit a5743f32baec4728711bbc01d6ac2b33d4c67040 ]
    
    Use BUILD_BUG_ON_MSG(statically_true(ulo > uhi), ...) for the sanity check
    of the bounds in clamp().  Gives better error coverage and one less
    expansion of the arguments.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: David Laight <[email protected]>
    Cc: Andy Shevchenko <[email protected]>
    Cc: Arnd Bergmann <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Dan Carpenter <[email protected]>
    Cc: Jason A. Donenfeld <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Cc: Mateusz Guzik <[email protected]>
    Cc: Matthew Wilcox <[email protected]>
    Cc: Pedro Falcato <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
minmax: don't use max() in situations that want a C constant expression [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Mon Sep 29 17:17:24 2025 +0000

    minmax: don't use max() in situations that want a C constant expression
    
    [ Upstream commit cb04e8b1d2f24c4c2c92f7b7529031fc35a16fed ]
    
    We only had a couple of array[] declarations, and changing them to just
    use 'MAX()' instead of 'max()' fixes the issue.
    
    This will allow us to simplify our min/max macros enormously, since they
    can now unconditionally use temporary variables to avoid using the
    argument values multiple times.
    
    Cc: David Laight <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

minmax: fix up min3() and max3() too [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Mon Sep 29 17:17:26 2025 +0000

    minmax: fix up min3() and max3() too
    
    [ Upstream commit 21b136cc63d2a9ddd60d4699552b69c214b32964 ]
    
    David Laight pointed out that we should deal with the min3() and max3()
    mess too, which still does excessive expansion.
    
    And our current macros are actually rather broken.
    
    In particular, the macros did this:
    
      #define min3(x, y, z) min((typeof(x))min(x, y), z)
      #define max3(x, y, z) max((typeof(x))max(x, y), z)
    
    and that not only is a nested expansion of possibly very complex
    arguments with all that involves, the typing with that "typeof()" cast
    is completely wrong.
    
    For example, imagine what happens in max3() if 'x' happens to be a
    'unsigned char', but 'y' and 'z' are 'unsigned long'.  The types are
    compatible, and there's no warning - but the result is just random
    garbage.
    
    No, I don't think we've ever hit that issue in practice, but since we
    now have sane infrastructure for doing this right, let's just use it.
    It fixes any excessive expansion, and also avoids these kinds of broken
    type issues.
    
    Requested-by: David Laight <[email protected]>
    Acked-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

minmax: improve macro expansion and type checking [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Mon Sep 29 17:17:25 2025 +0000

    minmax: improve macro expansion and type checking
    
    [ Upstream commit 22f5468731491e53356ba7c028f0fdea20b18e2c ]
    
    This clarifies the rules for min()/max()/clamp() type checking and makes
    them a much more efficient macro expansion.
    
    In particular, we now look at the type and range of the inputs to see
    whether they work together, generating a mask of acceptable comparisons,
    and then just verifying that the inputs have a shared case:
    
     - an expression with a signed type can be used for
        (1) signed comparisons
        (2) unsigned comparisons if it is statically known to have a
            non-negative value
    
     - an expression with an unsigned type can be used for
        (3) unsigned comparison
        (4) signed comparisons if the type is smaller than 'int' and thus
            the C integer promotion rules will make it signed anyway
    
    Here rule (1) and (3) are obvious, and rule (2) is important in order to
    allow obvious trivial constants to be used together with unsigned
    values.
    
    Rule (4) is not necessarily a good idea, but matches what we used to do,
    and we have extant cases of this situation in the kernel.  Notably with
    bcachefs having an expression like
    
            min(bch2_bucket_sectors_dirty(a), ca->mi.bucket_size)
    
    where bch2_bucket_sectors_dirty() returns an 's64', and
    'ca->mi.bucket_size' is of type 'u16'.
    
    Technically that bcachefs comparison is clearly sensible on a C type
    level, because the 'u16' will go through the normal C integer promotion,
    and become 'int', and then we're comparing two signed values and
    everything looks sane.
    
    However, it's not entirely clear that a 'min(s64,u16)' operation makes a
    lot of conceptual sense, and it's possible that we will remove rule (4).
    After all, the _reason_ we have these complicated type checks is exactly
    that the C type promotion rules are not very intuitive.
    
    But at least for now the rule is in place for backwards compatibility.
    
    Also note that rule (2) existed before, but is hugely relaxed by this
    commit.  It used to be true only for the simplest compile-time
    non-negative integer constants.  The new macro model will allow cases
    where the compiler can trivially see that an expression is non-negative
    even if it isn't necessarily a constant.
    
    For example, the amdgpu driver does
    
            min_t(size_t, sizeof(fru_info->serial), pia[addr] & 0x3F));
    
    because our old 'min()' macro would see that 'pia[addr] & 0x3F' is of
    type 'int' and clearly not a C constant expression, so doing a 'min()'
    with a 'size_t' is a signedness violation.
    
    Our new 'min()' macro still sees that 'pia[addr] & 0x3F' is of type
    'int', but is smart enough to also see that it is clearly non-negative,
    and thus would allow that case without any complaints.
    
    Cc: Arnd Bergmann <[email protected]>
    Cc: David Laight <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

minmax: make generic MIN() and MAX() macros available everywhere [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Mon Sep 29 17:17:22 2025 +0000

    minmax: make generic MIN() and MAX() macros available everywhere
    
    [ Upstream commit 1a251f52cfdc417c84411a056bc142cbd77baef4 ]
    
    This just standardizes the use of MIN() and MAX() macros, with the very
    traditional semantics.  The goal is to use these for C constant
    expressions and for top-level / static initializers, and so be able to
    simplify the min()/max() macros.
    
    These macro names were used by various kernel code - they are very
    traditional, after all - and all such users have been fixed up, with a
    few different approaches:
    
     - trivial duplicated macro definitions have been removed
    
       Note that 'trivial' here means that it's obviously kernel code that
       already included all the major kernel headers, and thus gets the new
       generic MIN/MAX macros automatically.
    
     - non-trivial duplicated macro definitions are guarded with #ifndef
    
       This is the "yes, they define their own versions, but no, the include
       situation is not entirely obvious, and maybe they don't get the
       generic version automatically" case.
    
     - strange use case #1
    
       A couple of drivers decided that the way they want to describe their
       versioning is with
    
            #define MAJ 1
            #define MIN 2
            #define DRV_VERSION __stringify(MAJ) "." __stringify(MIN)
    
       which adds zero value and I just did my Alexander the Great
       impersonation, and rewrote that pointless Gordian knot as
    
            #define DRV_VERSION "1.2"
    
       instead.
    
     - strange use case #2
    
       A couple of drivers thought that it's a good idea to have a random
       'MIN' or 'MAX' define for a value or index into a table, rather than
       the traditional macro that takes arguments.
    
       These values were re-written as C enum's instead. The new
       function-line macros only expand when followed by an open
       parenthesis, and thus don't clash with enum use.
    
    Happily, there weren't really all that many of these cases, and a lot of
    users already had the pattern of using '#ifndef' guarding (or in one
    case just using '#undef MIN') before defining their own private version
    that does the same thing. I left such cases alone.
    
    Cc: David Laight <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

minmax: simplify min()/max()/clamp() implementation [+ + +]
Author: Linus Torvalds <[email protected]>
Date:   Mon Sep 29 17:17:23 2025 +0000

    minmax: simplify min()/max()/clamp() implementation
    
    [ Upstream commit dc1c8034e31b14a2e5e212104ec508aec44ce1b9 ]
    
    Now that we no longer have any C constant expression contexts (ie array
    size declarations or static initializers) that use min() or max(), we
    can simpify the implementation by not having to worry about the result
    staying as a C constant expression.
    
    So now we can unconditionally just use temporary variables of the right
    type, and get rid of the excessive expansion that used to come from the
    use of
    
       __builtin_choose_expr(__is_constexpr(...), ..
    
    to pick the specialized code for constant expressions.
    
    Another expansion simplification is to pass the temporary variables (in
    addition to the original expression) to our __types_ok() macro.  That
    may superficially look like it complicates the macro, but when we only
    want the type of the expression, expanding the temporary variable names
    is much simpler and smaller than expanding the potentially complicated
    original expression.
    
    As a result, on my machine, doing a
    
      $ time make drivers/staging/media/atomisp/pci/isp/kernels/ynr/ynr_1.0/ia_css_ynr.host.i
    
    goes from
    
            real    0m16.621s
            user    0m15.360s
            sys     0m1.221s
    
    to
    
            real    0m2.532s
            user    0m2.091s
            sys     0m0.452s
    
    because the token expansion goes down dramatically.
    
    In particular, the longest line expansion (which was line 71 of that
    'ia_css_ynr.host.c' file) shrinks from 23,338kB (yes, 23MB for one
    single line) to "just" 1,444kB (now "only" 1.4MB).
    
    And yes, that line is still the line from hell, because it's doing
    multiple levels of "min()/max()" expansion thanks to some of them being
    hidden inside the uDIGIT_FITTING() macro.
    
    Lorenzo has a nice cleanup patch that makes that driver use inline
    functions instead of macros for sDIGIT_FITTING() and uDIGIT_FITTING(),
    which will fix that line once and for all, but the 16-fold reduction in
    this case does show why we need to simplify these helpers.
    
    Cc: David Laight <[email protected]>
    Cc: Lorenzo Stoakes <[email protected]>
    Signed-off-by: Linus Torvalds <[email protected]>
    Signed-off-by: Eliav Farber <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/gup: check ref_count instead of lru before migration [+ + +]
Author: Hugh Dickins <[email protected]>
Date:   Mon Sep 8 15:15:03 2025 -0700

    mm/gup: check ref_count instead of lru before migration
    
    [ Upstream commit 98c6d259319ecf6e8d027abd3f14b81324b8c0ad ]
    
    Patch series "mm: better GUP pin lru_add_drain_all()", v2.
    
    Series of lru_add_drain_all()-related patches, arising from recent mm/gup
    migration report from Will Deacon.
    
    This patch (of 5):
    
    Will Deacon reports:-
    
    When taking a longterm GUP pin via pin_user_pages(),
    __gup_longterm_locked() tries to migrate target folios that should not be
    longterm pinned, for example because they reside in a CMA region or
    movable zone.  This is done by first pinning all of the target folios
    anyway, collecting all of the longterm-unpinnable target folios into a
    list, dropping the pins that were just taken and finally handing the list
    off to migrate_pages() for the actual migration.
    
    It is critically important that no unexpected references are held on the
    folios being migrated, otherwise the migration will fail and
    pin_user_pages() will return -ENOMEM to its caller.  Unfortunately, it is
    relatively easy to observe migration failures when running pKVM (which
    uses pin_user_pages() on crosvm's virtual address space to resolve stage-2
    page faults from the guest) on a 6.15-based Pixel 6 device and this
    results in the VM terminating prematurely.
    
    In the failure case, 'crosvm' has called mlock(MLOCK_ONFAULT) on its
    mapping of guest memory prior to the pinning.  Subsequently, when
    pin_user_pages() walks the page-table, the relevant 'pte' is not present
    and so the faulting logic allocates a new folio, mlocks it with
    mlock_folio() and maps it in the page-table.
    
    Since commit 2fbb0c10d1e8 ("mm/munlock: mlock_page() munlock_page() batch
    by pagevec"), mlock/munlock operations on a folio (formerly page), are
    deferred.  For example, mlock_folio() takes an additional reference on the
    target folio before placing it into a per-cpu 'folio_batch' for later
    processing by mlock_folio_batch(), which drops the refcount once the
    operation is complete.  Processing of the batches is coupled with the LRU
    batch logic and can be forcefully drained with lru_add_drain_all() but as
    long as a folio remains unprocessed on the batch, its refcount will be
    elevated.
    
    This deferred batching therefore interacts poorly with the pKVM pinning
    scenario as we can find ourselves in a situation where the migration code
    fails to migrate a folio due to the elevated refcount from the pending
    mlock operation.
    
    Hugh Dickins adds:-
    
    !folio_test_lru() has never been a very reliable way to tell if an
    lru_add_drain_all() is worth calling, to remove LRU cache references to
    make the folio migratable: the LRU flag may be set even while the folio is
    held with an extra reference in a per-CPU LRU cache.
    
    5.18 commit 2fbb0c10d1e8 may have made it more unreliable.  Then 6.11
    commit 33dfe9204f29 ("mm/gup: clear the LRU flag of a page before adding
    to LRU batch") tried to make it reliable, by moving LRU flag clearing; but
    missed the mlock/munlock batches, so still unreliable as reported.
    
    And it turns out to be difficult to extend 33dfe9204f29's LRU flag
    clearing to the mlock/munlock batches: if they do benefit from batching,
    mlock/munlock cannot be so effective when easily suppressed while !LRU.
    
    Instead, switch to an expected ref_count check, which was more reliable
    all along: some more false positives (unhelpful drains) than before, and
    never a guarantee that the folio will prove migratable, but better.
    
    Note on PG_private_2: ceph and nfs are still using the deprecated
    PG_private_2 flag, with the aid of netfs and filemap support functions.
    Although it is consistently matched by an increment of folio ref_count,
    folio_expected_ref_count() intentionally does not recognize it, and ceph
    folio migration currently depends on that for PG_private_2 folios to be
    rejected.  New references to the deprecated flag are discouraged, so do
    not add it into the collect_longterm_unpinnable_folios() calculation: but
    longterm pinning of transiently PG_private_2 ceph and nfs folios (an
    uncommon case) may invoke a redundant lru_add_drain_all().  And this makes
    easy the backport to earlier releases: up to and including 6.12, btrfs
    also used PG_private_2, but without a ref_count increment.
    
    Note for stable backports: requires 6.16 commit 86ebd50224c0 ("mm:
    add folio_expected_ref_count() for reference count calculation").
    
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region")
    Signed-off-by: Hugh Dickins <[email protected]>
    Reported-by: Will Deacon <[email protected]>
    Closes: https://lore.kernel.org/linux-mm/[email protected]/
    Acked-by: Kiryl Shutsemau <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Cc: "Aneesh Kumar K.V" <[email protected]>
    Cc: Axel Rasmussen <[email protected]>
    Cc: Chris Li <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Jason Gunthorpe <[email protected]>
    Cc: Johannes Weiner <[email protected]>
    Cc: John Hubbard <[email protected]>
    Cc: Keir Fraser <[email protected]>
    Cc: Konstantin Khlebnikov <[email protected]>
    Cc: Li Zhe <[email protected]>
    Cc: Matthew Wilcox (Oracle) <[email protected]>
    Cc: Peter Xu <[email protected]>
    Cc: Rik van Riel <[email protected]>
    Cc: Shivank Garg <[email protected]>
    Cc: Vlastimil Babka <[email protected]>
    Cc: Wei Xu <[email protected]>
    Cc: yangge <[email protected]>
    Cc: Yuanchu Xie <[email protected]>
    Cc: Yu Zhao <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    [ Clean cherry-pick now into this tree ]
    Signed-off-by: Hugh Dickins <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mm/gup: local lru_add_drain() to avoid lru_add_drain_all() [+ + +]
Author: Hugh Dickins <[email protected]>
Date:   Mon Sep 8 15:16:53 2025 -0700

    mm/gup: local lru_add_drain() to avoid lru_add_drain_all()
    
    [ Upstream commit a09a8a1fbb374e0053b97306da9dbc05bd384685 ]
    
    In many cases, if collect_longterm_unpinnable_folios() does need to drain
    the LRU cache to release a reference, the cache in question is on this
    same CPU, and much more efficiently drained by a preliminary local
    lru_add_drain(), than the later cross-CPU lru_add_drain_all().
    
    Marked for stable, to counter the increase in lru_add_drain_all()s from
    "mm/gup: check ref_count instead of lru before migration".  Note for clean
    backports: can take 6.16 commit a03db236aebf ("gup: optimize longterm
    pin_user_pages() for large folio") first.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Hugh Dickins <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Cc: "Aneesh Kumar K.V" <[email protected]>
    Cc: Axel Rasmussen <[email protected]>
    Cc: Chris Li <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Jason Gunthorpe <[email protected]>
    Cc: Johannes Weiner <[email protected]>
    Cc: John Hubbard <[email protected]>
    Cc: Keir Fraser <[email protected]>
    Cc: Konstantin Khlebnikov <[email protected]>
    Cc: Li Zhe <[email protected]>
    Cc: Matthew Wilcox (Oracle) <[email protected]>
    Cc: Peter Xu <[email protected]>
    Cc: Rik van Riel <[email protected]>
    Cc: Shivank Garg <[email protected]>
    Cc: Vlastimil Babka <[email protected]>
    Cc: Wei Xu <[email protected]>
    Cc: Will Deacon <[email protected]>
    Cc: yangge <[email protected]>
    Cc: Yuanchu Xie <[email protected]>
    Cc: Yu Zhao <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    [ Resolved minor conflicts ]
    Signed-off-by: Hugh Dickins <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mm/gup: revert "mm: gup: fix infinite loop within __get_longterm_locked" [+ + +]
Author: David Hildenbrand <[email protected]>
Date:   Wed Jun 11 15:13:14 2025 +0200

    mm/gup: revert "mm: gup: fix infinite loop within __get_longterm_locked"
    
    [ Upstream commit 517f496e1e61bd169d585dab4dd77e7147506322 ]
    
    After commit 1aaf8c122918 ("mm: gup: fix infinite loop within
    __get_longterm_locked") we are able to longterm pin folios that are not
    supposed to get longterm pinned, simply because they temporarily have the
    LRU flag cleared (esp.  temporarily isolated).
    
    For example, two __get_longterm_locked() callers can race, or
    __get_longterm_locked() can race with anything else that temporarily
    isolates folios.
    
    The introducing commit mentions the use case of a driver that uses
    vm_ops->fault to insert pages allocated through cma_alloc() into the page
    tables, assuming they can later get longterm pinned.  These pages/ folios
    would never have the LRU flag set and consequently cannot get isolated.
    There is no known in-tree user making use of that so far, fortunately.
    
    To handle that in the future -- and avoid retrying forever to
    isolate/migrate them -- we will need a different mechanism for the CMA
    area *owner* to indicate that it actually already allocated the page and
    is fine with longterm pinning it.  The LRU flag is not suitable for that.
    
    Probably we can lookup the relevant CMA area and query the bitmap; we only
    have have to care about some races, probably.  If already allocated, we
    could just allow longterm pinning)
    
    Anyhow, let's fix the "must not be longterm pinned" problem first by
    reverting the original commit.
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 1aaf8c122918 ("mm: gup: fix infinite loop within __get_longterm_locked")
    Signed-off-by: David Hildenbrand <[email protected]>
    Closes: https://lore.kernel.org/all/20250522092755.GA3277597@tiffany/
    Reported-by: Hyesoo Yu <[email protected]>
    Reviewed-by: John Hubbard <[email protected]>
    Cc: Jason Gunthorpe <[email protected]>
    Cc: Peter Xu <[email protected]>
    Cc: Zhaoyang Huang <[email protected]>
    Cc: Aijun Sun <[email protected]>
    Cc: Alistair Popple <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    [ Revert v6.6.79 commit 933b08c0edfa ]
    Signed-off-by: Hugh Dickins <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
mm/hugetlb: fix folio is still mapped when deleted [+ + +]
Author: Jinjiang Tu <[email protected]>
Date:   Fri Sep 12 15:41:39 2025 +0800

    mm/hugetlb: fix folio is still mapped when deleted
    
    commit 7b7387650dcf2881fd8bb55bcf3c8bd6c9542dd7 upstream.
    
    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/[email protected]
    Fixes: 4aae8d1c051e ("mm/hugetlbfs: unmap pages if page fault raced with hole punch")
    Signed-off-by: Jinjiang Tu <[email protected]>
    Cc: David Hildenbrand <[email protected]>
    Cc: Kefeng Wang <[email protected]>
    Cc: Matthew Wilcox (Oracle) <[email protected]>
    Cc: Muchun Song <[email protected]>
    Cc: Oscar Salvador <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize() [+ + +]
Author: David Hildenbrand <[email protected]>
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/[email protected]
    Fixes: 8763cb45ab96 ("mm/migrate: new memory migration helper for use with device memory")
    Signed-off-by: David Hildenbrand <[email protected]>
    Cc: Jérôme Glisse <[email protected]>
    Cc: John Hubbard <[email protected]>
    Cc: Alistair Popple <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: David Hildenbrand <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mm: add folio_expected_ref_count() for reference count calculation [+ + +]
Author: Shivank Garg <[email protected]>
Date:   Wed Apr 30 10:01:51 2025 +0000

    mm: add folio_expected_ref_count() for reference count calculation
    
    [ Upstream commit 86ebd50224c0734d965843260d0dc057a9431c61 ]
    
    Patch series " JFS: Implement migrate_folio for jfs_metapage_aops" v5.
    
    This patchset addresses a warning that occurs during memory compaction due
    to JFS's missing migrate_folio operation.  The warning was introduced by
    commit 7ee3647243e5 ("migrate: Remove call to ->writepage") which added
    explicit warnings when filesystem don't implement migrate_folio.
    
    The syzbot reported following [1]:
      jfs_metapage_aops does not implement migrate_folio
      WARNING: CPU: 1 PID: 5861 at mm/migrate.c:955 fallback_migrate_folio mm/migrate.c:953 [inline]
      WARNING: CPU: 1 PID: 5861 at mm/migrate.c:955 move_to_new_folio+0x70e/0x840 mm/migrate.c:1007
      Modules linked in:
      CPU: 1 UID: 0 PID: 5861 Comm: syz-executor280 Not tainted 6.15.0-rc1-next-20250411-syzkaller #0 PREEMPT(full)
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
      RIP: 0010:fallback_migrate_folio mm/migrate.c:953 [inline]
      RIP: 0010:move_to_new_folio+0x70e/0x840 mm/migrate.c:1007
    
    To fix this issue, this series implement metapage_migrate_folio() for JFS
    which handles both single and multiple metapages per page configurations.
    
    While most filesystems leverage existing migration implementations like
    filemap_migrate_folio(), buffer_migrate_folio_norefs() or
    buffer_migrate_folio() (which internally used folio_expected_refs()),
    JFS's metapage architecture requires special handling of its private data
    during migration.  To support this, this series introduce the
    folio_expected_ref_count(), which calculates external references to a
    folio from page/swap cache, private data, and page table mappings.
    
    This standardized implementation replaces the previous ad-hoc
    folio_expected_refs() function and enables JFS to accurately determine
    whether a folio has unexpected references before attempting migration.
    
    Implement folio_expected_ref_count() to calculate expected folio reference
    counts from:
    - Page/swap cache (1 per page)
    - Private data (1)
    - Page table mappings (1 per map)
    
    While originally needed for page migration operations, this improved
    implementation standardizes reference counting by consolidating all
    refcount contributors into a single, reusable function that can benefit
    any subsystem needing to detect unexpected references to folios.
    
    The folio_expected_ref_count() returns the sum of these external
    references without including any reference the caller itself might hold.
    Callers comparing against the actual folio_ref_count() must account for
    their own references separately.
    
    Link: https://syzkaller.appspot.com/bug?extid=8bb6fd945af4e0ad9299 [1]
    Link: https://lkml.kernel.org/r/[email protected]
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: David Hildenbrand <[email protected]>
    Signed-off-by: Shivank Garg <[email protected]>
    Suggested-by: Matthew Wilcox <[email protected]>
    Co-developed-by: David Hildenbrand <[email protected]>
    Cc: Alistair Popple <[email protected]>
    Cc: Dave Kleikamp <[email protected]>
    Cc: Donet Tom <[email protected]>
    Cc: Jane Chu <[email protected]>
    Cc: Kefeng Wang <[email protected]>
    Cc: Zi Yan <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Stable-dep-of: 98c6d259319e ("mm/gup: check ref_count instead of lru before migration")
    [ Take the new function in mm.h, removing "const" from its parameter to stop
      build warnings; but avoid all the conflicts of using it in mm/migrate.c. ]
    Signed-off-by: Hugh Dickins <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mm: folio_may_be_lru_cached() unless folio_test_large() [+ + +]
Author: Hugh Dickins <[email protected]>
Date:   Mon Sep 8 15:23:15 2025 -0700

    mm: folio_may_be_lru_cached() unless folio_test_large()
    
    [ Upstream commit 2da6de30e60dd9bb14600eff1cc99df2fa2ddae3 ]
    
    mm/swap.c and mm/mlock.c agree to drain any per-CPU batch as soon as a
    large folio is added: so collect_longterm_unpinnable_folios() just wastes
    effort when calling lru_add_drain[_all]() on a large folio.
    
    But although there is good reason not to batch up PMD-sized folios, we
    might well benefit from batching a small number of low-order mTHPs (though
    unclear how that "small number" limitation will be implemented).
    
    So ask if folio_may_be_lru_cached() rather than !folio_test_large(), to
    insulate those particular checks from future change.  Name preferred to
    "folio_is_batchable" because large folios can well be put on a batch: it's
    just the per-CPU LRU caches, drained much later, which need care.
    
    Marked for stable, to counter the increase in lru_add_drain_all()s from
    "mm/gup: check ref_count instead of lru before migration".
    
    Link: https://lkml.kernel.org/r/[email protected]
    Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages allocated from CMA region")
    Signed-off-by: Hugh Dickins <[email protected]>
    Suggested-by: David Hildenbrand <[email protected]>
    Acked-by: David Hildenbrand <[email protected]>
    Cc: "Aneesh Kumar K.V" <[email protected]>
    Cc: Axel Rasmussen <[email protected]>
    Cc: Chris Li <[email protected]>
    Cc: Christoph Hellwig <[email protected]>
    Cc: Jason Gunthorpe <[email protected]>
    Cc: Johannes Weiner <[email protected]>
    Cc: John Hubbard <[email protected]>
    Cc: Keir Fraser <[email protected]>
    Cc: Konstantin Khlebnikov <[email protected]>
    Cc: Li Zhe <[email protected]>
    Cc: Matthew Wilcox (Oracle) <[email protected]>
    Cc: Peter Xu <[email protected]>
    Cc: Rik van Riel <[email protected]>
    Cc: Shivank Garg <[email protected]>
    Cc: Vlastimil Babka <[email protected]>
    Cc: Wei Xu <[email protected]>
    Cc: Will Deacon <[email protected]>
    Cc: yangge <[email protected]>
    Cc: Yuanchu Xie <[email protected]>
    Cc: Yu Zhao <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    [ Resolved conflicts in mm/swap.c ]
    Signed-off-by: Hugh Dickins <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

mm: migrate_device: use more folio in migrate_device_finalize() [+ + +]
Author: Kefeng Wang <[email protected]>
Date:   Mon Aug 26 14:58:12 2024 +0800

    mm: migrate_device: use more folio in migrate_device_finalize()
    
    commit 58bf8c2bf47550bc94fea9cafd2bc7304d97102c upstream.
    
    Saves a couple of calls to compound_head() and remove last two callers of
    putback_lru_page().
    
    Link: https://lkml.kernel.org/r/[email protected]
    Signed-off-by: Kefeng Wang <[email protected]>
    Reviewed-by: Vishal Moola (Oracle) <[email protected]>
    Reviewed-by: Alistair Popple <[email protected]>
    Cc: Baolin Wang <[email protected]>
    Cc: David Hildenbrand <[email protected]>
    Cc: Jonathan Corbet <[email protected]>
    Cc: Matthew Wilcox (Oracle) <[email protected]>
    Cc: Zi Yan <[email protected]>
    Signed-off-by: Andrew Morton <[email protected]>
    Signed-off-by: David Hildenbrand <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
mmc: sdhci-cadence: add Mobileye eyeQ support [+ + +]
Author: Benoît Monin <[email protected]>
Date:   Tue Jun 17 15:25:52 2025 +0200

    mmc: sdhci-cadence: add Mobileye eyeQ support
    
    [ Upstream commit 120ffe250dd95b5089d032f582c5be9e3a04b94b ]
    
    The MMC/SDHCI controller implemented by Mobileye needs the preset value
    quirks to configure the clock properly at speed slower than HS200.
    It otherwise works as a standard sd4hc controller.
    
    Signed-off-by: Benoît Monin <[email protected]>
    Link: https://lore.kernel.org/r/e97f409650495791e07484589e1666ead570fa12.1750156323.git.benoit.monin@bootlin.com
    Signed-off-by: Ulf Hansson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
net: allow alloc_skb_with_frags() to use MAX_SKB_FRAGS [+ + +]
Author: Jason Baron <[email protected]>
Date:   Mon Sep 22 15:19:57 2025 -0400

    net: allow alloc_skb_with_frags() to use MAX_SKB_FRAGS
    
    [ Upstream commit ca9f9cdc4de97d0221100b11224738416696163c ]
    
    Currently, alloc_skb_with_frags() will only fill (MAX_SKB_FRAGS - 1)
    slots. I think it should use all MAX_SKB_FRAGS slots, as callers of
    alloc_skb_with_frags() will size their allocation of frags based
    on MAX_SKB_FRAGS.
    
    This issue was discovered via a test patch that sets 'order' to 0
    in alloc_skb_with_frags(), which effectively tests/simulates high
    fragmentation. In this case sendmsg() on unix sockets will fail every
    time for large allocations. If the PAGE_SIZE is 4K, then data_len will
    request 68K or 17 pages, but alloc_skb_with_frags() can only allocate
    64K in this case or 16 pages.
    
    Fixes: 09c2c90705bb ("net: allow alloc_skb_with_frags() to allocate bigger packets")
    Signed-off-by: Jason Baron <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: lantiq_gswip: do also enable or disable cpu port [+ + +]
Author: Martin Schiller <[email protected]>
Date:   Tue Jun 11 15:54:28 2024 +0200

    net: dsa: lantiq_gswip: do also enable or disable cpu port
    
    [ Upstream commit 86b9ea6412af41914ef6549f85a849c3b987f4f3 ]
    
    Before commit 74be4babe72f ("net: dsa: do not enable or disable non user
    ports"), gswip_port_enable/disable() were also executed for the cpu port
    in gswip_setup() which disabled the cpu port during initialization.
    
    Let's restore this by removing the dsa_is_user_port checks. Also, let's
    clean up the gswip_port_enable() function so that we only have to check
    for the cpu port once. The operation reordering done here is safe.
    
    Signed-off-by: Martin Schiller <[email protected]>
    Acked-by: Hauke Mehrtens <[email protected]>
    Reviewed-by: Vladimir Oltean <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Stable-dep-of: c0054b25e2f1 ("net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()")
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup() [+ + +]
Author: Vladimir Oltean <[email protected]>
Date:   Thu Sep 18 10:21:41 2025 +0300

    net: dsa: lantiq_gswip: move gswip_add_single_port_br() call to port_setup()
    
    [ Upstream commit c0054b25e2f1045f47b4954cf13a539e5e6047df ]
    
    A port added to a "single port bridge" operates as standalone, and this
    is mutually exclusive to being part of a Linux bridge. In fact,
    gswip_port_bridge_join() calls gswip_add_single_port_br() with
    add=false, i.e. removes the port from the "single port bridge" to enable
    autonomous forwarding.
    
    The blamed commit seems to have incorrectly thought that ds->ops->port_enable()
    is called one time per port, during the setup phase of the switch.
    
    However, it is actually called during the ndo_open() implementation of
    DSA user ports, which is to say that this sequence of events:
    
    1. ip link set swp0 down
    2. ip link add br0 type bridge
    3. ip link set swp0 master br0
    4. ip link set swp0 up
    
    would cause swp0 to join back the "single port bridge" which step 3 had
    just removed it from.
    
    The correct DSA hook for one-time actions per port at switch init time
    is ds->ops->port_setup(). This is what seems to match the coder's
    intention; also see the comment at the beginning of the file:
    
     * At the initialization the driver allocates one bridge table entry for
       ~~~~~~~~~~~~~~~~~~~~~
     * each switch port which is used when the port is used without an
     * explicit bridge.
    
    Fixes: 8206e0ce96b3 ("net: dsa: lantiq: Add VLAN unaware bridge offloading")
    Signed-off-by: Vladimir Oltean <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Tested-by: Daniel Golle <[email protected]>
    Reviewed-by: Daniel Golle <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

net: dsa: lantiq_gswip: suppress -EINVAL errors for bridge FDB entries added to the CPU port [+ + +]
Author: Vladimir Oltean <[email protected]>
Date:   Thu Sep 18 10:21:42 2025 +0300

    net: dsa: lantiq_gswip: suppress -EINVAL errors for bridge FDB entries added to the CPU port
    
    [ Upstream commit 987afe147965ef7a8e7d144ffef0d70af14bb1d4 ]
    
    The blamed commit and others in that patch set started the trend
    of reusing existing DSA driver API for a new purpose: calling
    ds->ops->port_fdb_add() on the CPU port.
    
    The lantiq_gswip driver was not prepared to handle that, as can be seen
    from the many errors that Daniel presents in the logs:
    
    [  174.050000] gswip 1e108000.switch: port 2 failed to add fa:aa:72:f4:8b:1e vid 1 to fdb: -22
    [  174.060000] gswip 1e108000.switch lan2: entered promiscuous mode
    [  174.070000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 0 to fdb: -22
    [  174.090000] gswip 1e108000.switch: port 2 failed to add 00:01:02:03:04:02 vid 1 to fdb: -22
    [  174.090000] gswip 1e108000.switch: port 2 failed to delete fa:aa:72:f4:8b:1e vid 1 from fdb: -2
    
    The errors are because gswip_port_fdb() wants to get a handle to the
    bridge that originated these FDB events, to associate it with a FID.
    Absolutely honourable purpose, however this only works for user ports.
    
    To get the bridge that generated an FDB entry for the CPU port, one
    would need to look at the db.bridge.dev argument. But this was
    introduced in commit c26933639b54 ("net: dsa: request drivers to perform
    FDB isolation"), first appeared in v5.18, and when the blamed commit was
    introduced in v5.14, no such API existed.
    
    So the core DSA feature was introduced way too soon for lantiq_gswip.
    Not acting on these host FDB entries and suppressing any errors has no
    other negative effect, and practically returns us to not supporting the
    host filtering feature at all - peacefully, this time.
    
    Fixes: 10fae4ac89ce ("net: dsa: include bridge addresses which are local in the host fdb list")
    Reported-by: Daniel Golle <[email protected]>
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Signed-off-by: Vladimir Oltean <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Tested-by: Daniel Golle <[email protected]>
    Reviewed-by: Daniel Golle <[email protected]>
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
nexthop: Forbid FDB status change while nexthop is in a group [+ + +]
Author: Ido Schimmel <[email protected]>
Date:   Sun Sep 21 18:08:22 2025 +0300

    nexthop: Forbid FDB status change while nexthop is in a group
    
    [ Upstream commit 390b3a300d7872cef9588f003b204398be69ce08 ]
    
    The kernel forbids the creation of non-FDB nexthop groups with FDB
    nexthops:
    
     # ip nexthop add id 1 via 192.0.2.1 fdb
     # ip nexthop add id 2 group 1
     Error: Non FDB nexthop group cannot have fdb nexthops.
    
    And vice versa:
    
     # ip nexthop add id 3 via 192.0.2.2 dev dummy1
     # ip nexthop add id 4 group 3 fdb
     Error: FDB nexthop group can only have fdb nexthops.
    
    However, as long as no routes are pointing to a non-FDB nexthop group,
    the kernel allows changing the type of a nexthop from FDB to non-FDB and
    vice versa:
    
     # ip nexthop add id 5 via 192.0.2.2 dev dummy1
     # ip nexthop add id 6 group 5
     # ip nexthop replace id 5 via 192.0.2.2 fdb
     # echo $?
     0
    
    This configuration is invalid and can result in a NPD [1] since FDB
    nexthops are not associated with a nexthop device:
    
     # ip route add 198.51.100.1/32 nhid 6
     # ping 198.51.100.1
    
    Fix by preventing nexthop FDB status change while the nexthop is in a
    group:
    
     # ip nexthop add id 7 via 192.0.2.2 dev dummy1
     # ip nexthop add id 8 group 7
     # ip nexthop replace id 7 via 192.0.2.2 fdb
     Error: Cannot change nexthop FDB status while in a group.
    
    [1]
    BUG: kernel NULL pointer dereference, address: 00000000000003c0
    [...]
    Oops: Oops: 0000 [#1] SMP
    CPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014
    RIP: 0010:fib_lookup_good_nhc+0x1e/0x80
    [...]
    Call Trace:
     <TASK>
     fib_table_lookup+0x541/0x650
     ip_route_output_key_hash_rcu+0x2ea/0x970
     ip_route_output_key_hash+0x55/0x80
     __ip4_datagram_connect+0x250/0x330
     udp_connect+0x2b/0x60
     __sys_connect+0x9c/0xd0
     __x64_sys_connect+0x18/0x20
     do_syscall_64+0xa4/0x2a0
     entry_SYSCALL_64_after_hwframe+0x4b/0x53
    
    Fixes: 38428d68719c ("nexthop: support for fdb ecmp nexthops")
    Reported-by: [email protected]
    Closes: https://lore.kernel.org/netdev/[email protected]/
    Tested-by: [email protected]
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
octeontx2-pf: Fix potential use after free in otx2_tc_add_flow() [+ + +]
Author: Dan Carpenter <[email protected]>
Date:   Tue Sep 23 14:19:11 2025 +0300

    octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()
    
    [ Upstream commit d9c70e93ec5988ab07ad2a92d9f9d12867f02c56 ]
    
    This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"
    and then dereferences it on the next line.  Two lines later, we take
    a mutex so I don't think this is an RCU safe region.  Re-order it to do
    the dereferences before queuing up the free.
    
    Fixes: 68fbff68dbea ("octeontx2-pf: Add police action for TC flower")
    Signed-off-by: Dan Carpenter <[email protected]>
    Reviewed-by: Vadim Fedorenko <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Paolo Abeni <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
s390/cpum_cf: Fix uninitialized warning after backport of ce971233242b [+ + +]
Author: Nathan Chancellor <[email protected]>
Date:   Mon Sep 22 14:15:50 2025 -0700

    s390/cpum_cf: Fix uninitialized warning after backport of ce971233242b
    
    Upstream commit ce971233242b ("s390/cpum_cf: Deny all sampling events by
    counter PMU"), backported to 6.6 as commit d660c8d8142e ("s390/cpum_cf:
    Deny all sampling events by counter PMU"), implicitly depends on the
    unconditional initialization of err to -ENOENT added by upstream
    commit aa1ac98268cd ("s390/cpumf: Fix double free on error in
    cpumf_pmu_event_init()"). The latter change is missing from 6.6,
    resulting in an instance of -Wuninitialized, which is fairly obvious
    from looking at the actual diff.
    
      arch/s390/kernel/perf_cpum_cf.c:858:10: warning: variable 'err' is uninitialized when used here [-Wuninitialized]
        858 |                 return err;
            |                        ^~~
    
    Commit aa1ac98268cd ("s390/cpumf: Fix double free on error in
    cpumf_pmu_event_init()") depends on commit c70ca298036c ("perf/core:
    Simplify the perf_event_alloc() error path"), which is a part of a much
    larger series unsuitable for stable.
    
    Extract the unconditional initialization of err to -ENOENT from
    commit aa1ac98268cd ("s390/cpumf: Fix double free on error in
    cpumf_pmu_event_init()") and apply it to 6.6 as a standalone change to
    resolve the warning.
    
    Fixes: d660c8d8142e ("s390/cpum_cf: Deny all sampling events by counter PMU")
    Signed-off-by: Nathan Chancellor <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
scsi: ufs: mcq: Fix memory allocation checks for SQE and CQE [+ + +]
Author: Alok Tiwari <[email protected]>
Date:   Sun Sep 7 12:40:16 2025 -0700

    scsi: ufs: mcq: Fix memory allocation checks for SQE and CQE
    
    [ Upstream commit 5cb782ff3c62c837e4984b6ae9f5d9a423cd5088 ]
    
    Previous checks incorrectly tested the DMA addresses (dma_handle) for
    NULL. Since dma_alloc_coherent() returns the CPU (virtual) address, the
    NULL check should be performed on the *_base_addr pointer to correctly
    detect allocation failures.
    
    Update the checks to validate sqe_base_addr and cqe_base_addr instead of
    sqe_dma_addr and cqe_dma_addr.
    
    Fixes: 4682abfae2eb ("scsi: ufs: core: mcq: Allocate memory for MCQ mode")
    Signed-off-by: Alok Tiwari <[email protected]>
    Reviewed-by: Alim Akhtar <[email protected]>
    Reviewed-by: Manivannan Sadhasivam <[email protected]>
    Reviewed-by: Peter Wang <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>
 
selftests: fib_nexthops: Fix creation of non-FDB nexthops [+ + +]
Author: Ido Schimmel <[email protected]>
Date:   Sun Sep 21 18:08:23 2025 +0300

    selftests: fib_nexthops: Fix creation of non-FDB nexthops
    
    [ Upstream commit c29913109c70383cdf90b6fc792353e1009f24f5 ]
    
    The test creates non-FDB nexthops without a nexthop device which leads
    to the expected failure, but for the wrong reason:
    
     # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
    
     IPv6 fdb groups functional
     --------------------------
     [...]
     COMMAND: ip -netns me-nRsN3E nexthop add id 63 via 2001:db8:91::4
     Error: Device attribute required for non-blackhole and non-fdb nexthops.
     COMMAND: ip -netns me-nRsN3E nexthop add id 64 via 2001:db8:91::5
     Error: Device attribute required for non-blackhole and non-fdb nexthops.
     COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 63/64 fdb
     Error: Invalid nexthop id.
     TEST: Fdb Nexthop group with non-fdb nexthops                       [ OK ]
     [...]
    
     IPv4 fdb groups functional
     --------------------------
     [...]
     COMMAND: ip -netns me-nRsN3E nexthop add id 14 via 172.16.1.2
     Error: Device attribute required for non-blackhole and non-fdb nexthops.
     COMMAND: ip -netns me-nRsN3E nexthop add id 15 via 172.16.1.3
     Error: Device attribute required for non-blackhole and non-fdb nexthops.
     COMMAND: ip -netns me-nRsN3E nexthop add id 103 group 14/15 fdb
     Error: Invalid nexthop id.
     TEST: Fdb Nexthop group with non-fdb nexthops                       [ OK ]
    
     COMMAND: ip -netns me-nRsN3E nexthop add id 16 via 172.16.1.2 fdb
     COMMAND: ip -netns me-nRsN3E nexthop add id 17 via 172.16.1.3 fdb
     COMMAND: ip -netns me-nRsN3E nexthop add id 104 group 14/15
     Error: Invalid nexthop id.
     TEST: Non-Fdb Nexthop group with fdb nexthops                       [ OK ]
     [...]
     COMMAND: ip -netns me-0dlhyd ro add 172.16.0.0/22 nhid 15
     Error: Nexthop id does not exist.
     TEST: Route add with fdb nexthop                                    [ OK ]
    
    In addition, as can be seen in the above output, a couple of IPv4 test
    cases used the non-FDB nexthops (14 and 15) when they intended to use
    the FDB nexthops (16 and 17). These test cases only passed because
    failure was expected, but they failed for the wrong reason.
    
    Fix the test to create the non-FDB nexthops with a nexthop device and
    adjust the IPv4 test cases to use the FDB nexthops instead of the
    non-FDB nexthops.
    
    Output after the fix:
    
     # ./fib_nexthops.sh -t "ipv6_fdb_grp_fcnal ipv4_fdb_grp_fcnal" -v
    
     IPv6 fdb groups functional
     --------------------------
     [...]
     COMMAND: ip -netns me-lNzfHP nexthop add id 63 via 2001:db8:91::4 dev veth1
     COMMAND: ip -netns me-lNzfHP nexthop add id 64 via 2001:db8:91::5 dev veth1
     COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 63/64 fdb
     Error: FDB nexthop group can only have fdb nexthops.
     TEST: Fdb Nexthop group with non-fdb nexthops                       [ OK ]
     [...]
    
     IPv4 fdb groups functional
     --------------------------
     [...]
     COMMAND: ip -netns me-lNzfHP nexthop add id 14 via 172.16.1.2 dev veth1
     COMMAND: ip -netns me-lNzfHP nexthop add id 15 via 172.16.1.3 dev veth1
     COMMAND: ip -netns me-lNzfHP nexthop add id 103 group 14/15 fdb
     Error: FDB nexthop group can only have fdb nexthops.
     TEST: Fdb Nexthop group with non-fdb nexthops                       [ OK ]
    
     COMMAND: ip -netns me-lNzfHP nexthop add id 16 via 172.16.1.2 fdb
     COMMAND: ip -netns me-lNzfHP nexthop add id 17 via 172.16.1.3 fdb
     COMMAND: ip -netns me-lNzfHP nexthop add id 104 group 16/17
     Error: Non FDB nexthop group cannot have fdb nexthops.
     TEST: Non-Fdb Nexthop group with fdb nexthops                       [ OK ]
     [...]
     COMMAND: ip -netns me-lNzfHP ro add 172.16.0.0/22 nhid 16
     Error: Route cannot point to a fdb nexthop.
     TEST: Route add with fdb nexthop                                    [ OK ]
     [...]
     Tests passed:  30
     Tests failed:   0
     Tests skipped:  0
    
    Fixes: 0534c5489c11 ("selftests: net: add fdb nexthop tests")
    Signed-off-by: Ido Schimmel <[email protected]>
    Reviewed-by: David Ahern <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
smb: client: fix wrong index reference in smb2_compound_op() [+ + +]
Author: Sang-Heon Jeon <[email protected]>
Date:   Tue Sep 23 17:16:45 2025 +0900

    smb: client: fix wrong index reference in smb2_compound_op()
    
    [ Upstream commit fbe2dc6a9c7318f7263f5e4d50f6272b931c5756 ]
    
    In smb2_compound_op(), the loop that processes each command's response
    uses wrong indices when accessing response bufferes.
    
    This incorrect indexing leads to improper handling of command results.
    Also, if incorrectly computed index is greather than or equal to
    MAX_COMPOUND, it can cause out-of-bounds accesses.
    
    Fixes: 3681c74d342d ("smb: client: handle lack of EA support in smb2_query_path_info()") # 6.14
    Reviewed-by: Paulo Alcantara (Red Hat) <[email protected]>
    Signed-off-by: Sang-Heon Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

smb: server: don't use delayed_work for post_recv_credits_work [+ + +]
Author: Stefan Metzmacher <[email protected]>
Date:   Fri Aug 8 17:55:17 2025 +0200

    smb: server: don't use delayed_work for post_recv_credits_work
    
    [ Upstream commit 1cde0a74a7a8951b3097417847a458e557be0b5b ]
    
    If we are using a hardcoded delay of 0 there's no point in
    using delayed_work it only adds confusion.
    
    The client also uses a normal work_struct and now
    it is easier to move it to the common smbdirect_socket.
    
    Cc: Namjae Jeon <[email protected]>
    Cc: Steve French <[email protected]>
    Cc: Tom Talpey <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers")
    Signed-off-by: Stefan Metzmacher <[email protected]>
    Acked-by: Namjae Jeon <[email protected]>
    Signed-off-by: Steve French <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
tracing: dynevent: Add a missing lockdown check on dynevent [+ + +]
Author: Masami Hiramatsu (Google) <[email protected]>
Date:   Fri Sep 19 10:15:56 2025 +0900

    tracing: dynevent: Add a missing lockdown check on dynevent
    
    commit 456c32e3c4316654f95f9d49c12cbecfb77d5660 upstream.
    
    Since dynamic_events interface on tracefs is compatible with
    kprobe_events and uprobe_events, it should also check the lockdown
    status and reject if it is set.
    
    Link: https://lore.kernel.org/all/175824455687.45175.3734166065458520748.stgit@devnote2/
    
    Fixes: 17911ff38aa5 ("tracing: Add locked_down checks to the open calls of files created for tracefs")
    Signed-off-by: Masami Hiramatsu (Google) <[email protected]>
    Cc: [email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

 
usb: core: Add 0x prefix to quirks debug output [+ + +]
Author: Jiayi Li <[email protected]>
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 <[email protected]>
    Link: https://lore.kernel.org/r/[email protected]
    Signed-off-by: Greg Kroah-Hartman <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
vhost: Take a reference on the task in struct vhost_task. [+ + +]
Author: Sebastian Andrzej Siewior <[email protected]>
Date:   Thu Sep 18 20:11:44 2025 +0200

    vhost: Take a reference on the task in struct vhost_task.
    
    [ Upstream commit afe16653e05db07d658b55245c7a2e0603f136c0 ]
    
    vhost_task_create() creates a task and keeps a reference to its
    task_struct. That task may exit early via a signal and its task_struct
    will be released.
    A pending vhost_task_wake() will then attempt to wake the task and
    access a task_struct which is no longer there.
    
    Acquire a reference on the task_struct while creating the thread and
    release the reference while the struct vhost_task itself is removed.
    If the task exits early due to a signal, then the vhost_task_wake() will
    still access a valid task_struct. The wake is safe and will be skipped
    in this case.
    
    Fixes: f9010dbdce911 ("fork, vhost: Use CLONE_THREAD to fix freezer/ps regression")
    Reported-by: Sean Christopherson <[email protected]>
    Closes: https://lore.kernel.org/all/[email protected]/
    Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
    Message-Id: <[email protected]>
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Tested-by: Sean Christopherson <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
wifi: virt_wifi: Fix page fault on connect [+ + +]
Author: James Guan <[email protected]>
Date:   Wed Sep 10 19:19:29 2025 +0800

    wifi: virt_wifi: Fix page fault on connect
    
    [ Upstream commit 9c600589e14f5fc01b8be9a5d0ad1f094b8b304b ]
    
    This patch prevents page fault in __cfg80211_connect_result()[1]
    when connecting a virt_wifi device, while ensuring that virt_wifi
    can connect properly.
    
    [1] https://lore.kernel.org/linux-wireless/[email protected]/
    
    Closes: https://lore.kernel.org/linux-wireless/[email protected]/
    Signed-off-by: James Guan <[email protected]>
    Link: https://patch.msgid.link/[email protected]
    [remove irrelevant network-manager instructions]
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>

 
xfrm: xfrm_alloc_spi shouldn't use 0 as SPI [+ + +]
Author: Sabrina Dubroca <[email protected]>
Date:   Fri Aug 29 10:54:15 2025 +0200

    xfrm: xfrm_alloc_spi shouldn't use 0 as SPI
    
    [ Upstream commit cd8ae32e4e4652db55bce6b9c79267d8946765a9 ]
    
    x->id.spi == 0 means "no SPI assigned", but since commit
    94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create states
    and add them to the byspi list with this value.
    
    __xfrm_state_delete doesn't remove those states from the byspi list,
    since they shouldn't be there, and this shows up as a UAF the next
    time we go through the byspi list.
    
    Reported-by: [email protected]
    Closes: https://syzkaller.appspot.com/bug?extid=a25ee9d20d31e483ba7b
    Fixes: 94f39804d891 ("xfrm: Duplicate SPI Handling")
    Signed-off-by: Sabrina Dubroca <[email protected]>
    Reviewed-by: Simon Horman <[email protected]>
    Signed-off-by: Steffen Klassert <[email protected]>
    Signed-off-by: Sasha Levin <[email protected]>