Changelog in Linux kernel 6.12.22

 
ALSA: hda/realtek: Support mute LED on HP Laptop 15s-du3xxx [+ + +]
Author: Dhruv Deshpande <dhrv.d@proton.me>
Date:   Mon Mar 17 08:56:53 2025 +0000

    ALSA: hda/realtek: Support mute LED on HP Laptop 15s-du3xxx
    
    commit 35ef1c79d2e09e9e5a66e28a66fe0df4368b0f3d upstream.
    
    The mute LED on this HP laptop uses ALC236 and requires a quirk to function.
    This patch enables the existing quirk for the device.
    
    Tested on my laptop and the LED behaviour works as intended.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Dhruv Deshpande <dhrv.d@proton.me>
    Link: https://patch.msgid.link/20250317085621.45056-1-dhrv.d@proton.me
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ALSA: usb-audio: Add quirk for Plantronics headsets to fix control names [+ + +]
Author: Terry Junge <linuxhid@cosmicgizmosystems.com>
Date:   Fri Jan 17 16:58:39 2025 -0800

    ALSA: usb-audio: Add quirk for Plantronics headsets to fix control names
    
    commit 486f6205c233da1baa309bde5f634eb1f8319a33 upstream.
    
    Many Poly/Plantronics headset families name the feature, input,
    and/or output units in a such a way to produce control names
    that are not recognized by user space. As such, the volume and
    mute events do not get routed to the headset's audio controls.
    
    As an example from a product family:
    
    The microphone mute control is named
    Headset Microphone Capture Switch
    and the headset volume control is named
    Headset Earphone Playback Volume
    
    The quirk fixes these to become
    Headset Capture Switch
    Headset Playback Volume
    
    Signed-off-by: Terry Junge <linuxhid@cosmicgizmosystems.com>
    Reviewed-by: Takashi Iwai <tiwai@suse.de>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 
atm: Fix NULL pointer dereference [+ + +]
Author: Minjoong Kim <pwn9uin@gmail.com>
Date:   Sat Mar 22 10:52:00 2025 +0000

    atm: Fix NULL pointer dereference
    
    commit bf2986fcf82a449441f9ee4335df19be19e83970 upstream.
    
    When MPOA_cache_impos_rcvd() receives the msg, it can trigger
    Null Pointer Dereference Vulnerability if both entry and
    holding_time are NULL. Because there is only for the situation
    where entry is NULL and holding_time exists, it can be passed
    when both entry and holding_time are NULL. If these are NULL,
    the entry will be passd to eg_cache_put() as parameter and
    it is referenced by entry->use code in it.
    
    kasan log:
    
    [    3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I
    [    3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
    [    3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102
    [    3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
    [    3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
    [    3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
    [    3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
    [    3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
    [    3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
    [    3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
    [    3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
    [    3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
    [    3.324185] FS:  000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
    [    3.325042] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
    [    3.326430] Call Trace:
    [    3.326725]  <TASK>
    [    3.326927]  ? die_addr+0x3c/0xa0
    [    3.327330]  ? exc_general_protection+0x161/0x2a0
    [    3.327662]  ? asm_exc_general_protection+0x26/0x30
    [    3.328214]  ? vprintk_emit+0x15e/0x420
    [    3.328543]  ? eg_cache_remove_entry+0xa5/0x470
    [    3.328910]  ? eg_cache_remove_entry+0x9a/0x470
    [    3.329294]  ? __pfx_eg_cache_remove_entry+0x10/0x10
    [    3.329664]  ? console_unlock+0x107/0x1d0
    [    3.329946]  ? __pfx_console_unlock+0x10/0x10
    [    3.330283]  ? do_syscall_64+0xa6/0x1a0
    [    3.330584]  ? entry_SYSCALL_64_after_hwframe+0x47/0x7f
    [    3.331090]  ? __pfx_prb_read_valid+0x10/0x10
    [    3.331395]  ? down_trylock+0x52/0x80
    [    3.331703]  ? vprintk_emit+0x15e/0x420
    [    3.331986]  ? __pfx_vprintk_emit+0x10/0x10
    [    3.332279]  ? down_trylock+0x52/0x80
    [    3.332527]  ? _printk+0xbf/0x100
    [    3.332762]  ? __pfx__printk+0x10/0x10
    [    3.333007]  ? _raw_write_lock_irq+0x81/0xe0
    [    3.333284]  ? __pfx__raw_write_lock_irq+0x10/0x10
    [    3.333614]  msg_from_mpoad+0x1185/0x2750
    [    3.333893]  ? __build_skb_around+0x27b/0x3a0
    [    3.334183]  ? __pfx_msg_from_mpoad+0x10/0x10
    [    3.334501]  ? __alloc_skb+0x1c0/0x310
    [    3.334809]  ? __pfx___alloc_skb+0x10/0x10
    [    3.335283]  ? _raw_spin_lock+0xe0/0xe0
    [    3.335632]  ? finish_wait+0x8d/0x1e0
    [    3.335975]  vcc_sendmsg+0x684/0xba0
    [    3.336250]  ? __pfx_vcc_sendmsg+0x10/0x10
    [    3.336587]  ? __pfx_autoremove_wake_function+0x10/0x10
    [    3.337056]  ? fdget+0x176/0x3e0
    [    3.337348]  __sys_sendto+0x4a2/0x510
    [    3.337663]  ? __pfx___sys_sendto+0x10/0x10
    [    3.337969]  ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400
    [    3.338364]  ? sock_ioctl+0x1bb/0x5a0
    [    3.338653]  ? __rseq_handle_notify_resume+0x825/0xd20
    [    3.339017]  ? __pfx_sock_ioctl+0x10/0x10
    [    3.339316]  ? __pfx___rseq_handle_notify_resume+0x10/0x10
    [    3.339727]  ? selinux_file_ioctl+0xa4/0x260
    [    3.340166]  __x64_sys_sendto+0xe0/0x1c0
    [    3.340526]  ? syscall_exit_to_user_mode+0x123/0x140
    [    3.340898]  do_syscall_64+0xa6/0x1a0
    [    3.341170]  entry_SYSCALL_64_after_hwframe+0x77/0x7f
    [    3.341533] RIP: 0033:0x44a380
    [    3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00
    [    3.343078] RSP: 002b:00007ffc1d404098 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
    [    3.343631] RAX: ffffffffffffffda RBX: 00007ffc1d404458 RCX: 000000000044a380
    [    3.344306] RDX: 000000000000019c RSI: 00007ffc1d4040b0 RDI: 0000000000000003
    [    3.344833] RBP: 00007ffc1d404260 R08: 0000000000000000 R09: 0000000000000000
    [    3.345381] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
    [    3.346015] R13: 00007ffc1d404448 R14: 00000000004c17d0 R15: 0000000000000001
    [    3.346503]  </TASK>
    [    3.346679] Modules linked in:
    [    3.346956] ---[ end trace 0000000000000000 ]---
    [    3.347315] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
    [    3.347737] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
    [    3.349157] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
    [    3.349517] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
    [    3.350103] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
    [    3.350610] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
    [    3.351246] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
    [    3.351785] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
    [    3.352404] FS:  000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
    [    3.353099] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [    3.353544] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
    [    3.354072] note: ex[79] exited with irqs disabled
    [    3.354458] note: ex[79] exited with preempt_count 1
    
    Signed-off-by: Minjoong Kim <pwn9uin@gmail.com>
    Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
    Reviewed-by: Simon Horman <horms@kernel.org>
    Link: https://patch.msgid.link/20250322105200.14981-1-pwn9uin@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
bcachefs: bch2_ioctl_subvolume_destroy() fixes [+ + +]
Author: Kent Overstreet <kent.overstreet@linux.dev>
Date:   Sat Mar 29 19:01:09 2025 -0400

    bcachefs: bch2_ioctl_subvolume_destroy() fixes
    
    [ Upstream commit 707549600c4a012ed71c0204a7992a679880bf33 ]
    
    bch2_evict_subvolume_inodes() was getting stuck - due to incorrectly
    pruning the dcache.
    
    Also, fix missing permissions checks.
    
    Reported-by: Alexander Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
counter: microchip-tcb-capture: Fix undefined counter channel state on probe [+ + +]
Author: William Breathitt Gray <wbg@kernel.org>
Date:   Wed Mar 5 19:01:19 2025 +0900

    counter: microchip-tcb-capture: Fix undefined counter channel state on probe
    
    commit c0c9c73434666dc99ee156b25e7e722150bee001 upstream.
    
    Hardware initialize of the timer counter channel does not occur on probe
    thus leaving the Count in an undefined state until the first
    function_write() callback is executed. Fix this by performing the proper
    hardware initialization during probe.
    
    Fixes: 106b104137fd ("counter: Add microchip TCB capture counter")
    Reported-by: Csókás Bence <csokas.bence@prolan.hu>
    Closes: https://lore.kernel.org/all/bfa70e78-3cc3-4295-820b-3925c26135cb@prolan.hu/
    Link: https://lore.kernel.org/r/20250305-preset-capture-mode-microchip-tcb-capture-v1-1-632c95c6421e@kernel.org
    Signed-off-by: William Breathitt Gray <wbg@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

counter: stm32-lptimer-cnt: fix error handling when enabling [+ + +]
Author: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Date:   Mon Feb 24 18:06:57 2025 +0100

    counter: stm32-lptimer-cnt: fix error handling when enabling
    
    commit 8744dcd4fc7800de2eb9369410470bb2930d4c14 upstream.
    
    In case the stm32_lptim_set_enable_state() fails to update CMP and ARR,
    a timeout error is raised, by regmap_read_poll_timeout. It may happen,
    when the lptimer runs on a slow clock, and the clock is gated only
    few times during the polling.
    
    Badly, when this happen, STM32_LPTIM_ENABLE in CR register has been set.
    So the 'enable' state in sysfs wrongly lies on the counter being
    correctly enabled, due to CR is read as one in stm32_lptim_is_enabled().
    
    To fix both issues:
    - enable the clock before writing CMP, ARR and polling ISR bits. It will
    avoid the possible timeout error.
    - clear the ENABLE bit in CR and disable the clock in the error path.
    
    Fixes: d8958824cf07 ("iio: counter: Add support for STM32 LPTimer")
    Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
    Link: https://lore.kernel.org/r/20250224170657.3368236-1-fabrice.gasnier@foss.st.com
    Signed-off-by: William Breathitt Gray <wbg@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
drm/amd/display: Don't write DP_MSTM_CTRL after LT [+ + +]
Author: Wayne Lin <Wayne.Lin@amd.com>
Date:   Fri Oct 25 12:27:26 2024 +0800

    drm/amd/display: Don't write DP_MSTM_CTRL after LT
    
    commit bc068194f548ef1f230d96c4398046bf59165992 upstream.
    
    [Why]
    Observe after suspend/resme, we can't light up mst monitors under specific
    mst hub. The reason is that driver still writes DPCD DP_MSTM_CTRL after LT.
    It's forbidden even we write the same value for that dpcd register.
    
    [How]
    We already resume the mst branch device dpcd settings during
    resume_mst_branch_status(). Leverage drm_dp_mst_topology_queue_probe() to
    only probe the topology, not calling drm_dp_mst_topology_mgr_resume() which
    will set DP_MSTM_CTRL as well.
    
    Reviewed-by: Jerry Zuo <jerry.zuo@amd.com>
    Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
    Signed-off-by: Zaeem Mohamed <zaeem.mohamed@amd.com>
    Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
HID: hid-plantronics: Add mic mute mapping and generalize quirks [+ + +]
Author: Terry Junge <linuxhid@cosmicgizmosystems.com>
Date:   Fri Jan 17 16:58:38 2025 -0800

    HID: hid-plantronics: Add mic mute mapping and generalize quirks
    
    commit 9821709af892be9fbf4ee9a50b2f3e0604295ce0 upstream.
    
    Add mapping for headset mute key events.
    
    Remove PLT_QUIRK_DOUBLE_VOLUME_KEYS quirk and made it generic.
    The quirk logic did not keep track of the actual previous key
    so any key event occurring in less than or equal to 5ms was ignored.
    
    Remove PLT_QUIRK_FOLLOWED_OPPOSITE_VOLUME_KEYS quirk.
    It had the same logic issue as the double key quirk and was actually
    masking the as designed behavior of most of the headsets.
    It's occurrence should be minimized with the ALSA control naming
    quirk that is part of the patch set.
    
    Signed-off-by: Terry Junge <linuxhid@cosmicgizmosystems.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Jiri Kosina <jkosina@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
Linux: Linux 6.12.22 [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Apr 7 10:08:37 2025 +0200

    Linux 6.12.22
    
    Link: https://lore.kernel.org/r/20250403151622.055059925@linuxfoundation.org
    Tested-by: Markus Reichelt <lkt+2023@mareichelt.com>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Tested-by: Peter Schneider <pschneider1968@googlemail.com>
    Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
    Tested-by: Mark Brown <broonie@kernel.org>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Ron Economos <re@w6rz.net>
    Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove [+ + +]
Author: Luo Qiu <luoqiu@kylinsec.com.cn>
Date:   Mon Mar 17 18:14:38 2025 +0800

    memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
    
    commit 4676741a3464b300b486e70585c3c9b692be1632 upstream.
    
    This fixes the following crash:
    
    ==================================================================
    BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
    Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
    
    CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G            E      6.14.0-rc6+ #1
    Tainted: [E]=UNSIGNED_MODULE
    Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024
    Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]
    Call Trace:
     <TASK>
     dump_stack_lvl+0x51/0x70
     print_address_description.constprop.0+0x27/0x320
     ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
     print_report+0x3e/0x70
     kasan_report+0xab/0xe0
     ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
     rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]
     ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]
     ? __pfx___schedule+0x10/0x10
     ? kick_pool+0x3b/0x270
     process_one_work+0x357/0x660
     worker_thread+0x390/0x4c0
     ? __pfx_worker_thread+0x10/0x10
     kthread+0x190/0x1d0
     ? __pfx_kthread+0x10/0x10
     ret_from_fork+0x2d/0x50
     ? __pfx_kthread+0x10/0x10
     ret_from_fork_asm+0x1a/0x30
     </TASK>
    
    Allocated by task 161446:
     kasan_save_stack+0x20/0x40
     kasan_save_track+0x10/0x30
     __kasan_kmalloc+0x7b/0x90
     __kmalloc_noprof+0x1a7/0x470
     memstick_alloc_host+0x1f/0xe0 [memstick]
     rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]
     platform_probe+0x60/0xe0
     call_driver_probe+0x35/0x120
     really_probe+0x123/0x410
     __driver_probe_device+0xc7/0x1e0
     driver_probe_device+0x49/0xf0
     __device_attach_driver+0xc6/0x160
     bus_for_each_drv+0xe4/0x160
     __device_attach+0x13a/0x2b0
     bus_probe_device+0xbd/0xd0
     device_add+0x4a5/0x760
     platform_device_add+0x189/0x370
     mfd_add_device+0x587/0x5e0
     mfd_add_devices+0xb1/0x130
     rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]
     usb_probe_interface+0x15c/0x460
     call_driver_probe+0x35/0x120
     really_probe+0x123/0x410
     __driver_probe_device+0xc7/0x1e0
     driver_probe_device+0x49/0xf0
     __device_attach_driver+0xc6/0x160
     bus_for_each_drv+0xe4/0x160
     __device_attach+0x13a/0x2b0
     rebind_marked_interfaces.isra.0+0xcc/0x110
     usb_reset_device+0x352/0x410
     usbdev_do_ioctl+0xe5c/0x1860
     usbdev_ioctl+0xa/0x20
     __x64_sys_ioctl+0xc5/0xf0
     do_syscall_64+0x59/0x170
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Freed by task 161506:
     kasan_save_stack+0x20/0x40
     kasan_save_track+0x10/0x30
     kasan_save_free_info+0x36/0x60
     __kasan_slab_free+0x34/0x50
     kfree+0x1fd/0x3b0
     device_release+0x56/0xf0
     kobject_cleanup+0x73/0x1c0
     rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]
     platform_remove+0x2f/0x50
     device_release_driver_internal+0x24b/0x2e0
     bus_remove_device+0x124/0x1d0
     device_del+0x239/0x530
     platform_device_del.part.0+0x19/0xe0
     platform_device_unregister+0x1c/0x40
     mfd_remove_devices_fn+0x167/0x170
     device_for_each_child_reverse+0xc9/0x130
     mfd_remove_devices+0x6e/0xa0
     rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]
     usb_unbind_interface+0xf3/0x3f0
     device_release_driver_internal+0x24b/0x2e0
     proc_disconnect_claim+0x13d/0x220
     usbdev_do_ioctl+0xb5e/0x1860
     usbdev_ioctl+0xa/0x20
     __x64_sys_ioctl+0xc5/0xf0
     do_syscall_64+0x59/0x170
     entry_SYSCALL_64_after_hwframe+0x76/0x7e
    
    Last potentially related work creation:
     kasan_save_stack+0x20/0x40
     kasan_record_aux_stack+0x85/0x90
     insert_work+0x29/0x100
     __queue_work+0x34a/0x540
     call_timer_fn+0x2a/0x160
     expire_timers+0x5f/0x1f0
     __run_timer_base.part.0+0x1b6/0x1e0
     run_timer_softirq+0x8b/0xe0
     handle_softirqs+0xf9/0x360
     __irq_exit_rcu+0x114/0x130
     sysvec_apic_timer_interrupt+0x72/0x90
     asm_sysvec_apic_timer_interrupt+0x16/0x20
    
    Second to last potentially related work creation:
     kasan_save_stack+0x20/0x40
     kasan_record_aux_stack+0x85/0x90
     insert_work+0x29/0x100
     __queue_work+0x34a/0x540
     call_timer_fn+0x2a/0x160
     expire_timers+0x5f/0x1f0
     __run_timer_base.part.0+0x1b6/0x1e0
     run_timer_softirq+0x8b/0xe0
     handle_softirqs+0xf9/0x360
     __irq_exit_rcu+0x114/0x130
     sysvec_apic_timer_interrupt+0x72/0x90
     asm_sysvec_apic_timer_interrupt+0x16/0x20
    
    The buggy address belongs to the object at ffff888136335000
     which belongs to the cache kmalloc-2k of size 2048
    The buggy address is located 896 bytes inside of
     freed 2048-byte region [ffff888136335000, ffff888136335800)
    
    The buggy address belongs to the physical page:
    page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x136330
    head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
    flags: 0x17ffffc0000040(head|node=0|zone=2|lastcpupid=0x1fffff)
    page_type: f5(slab)
    raw: 0017ffffc0000040 ffff888100042f00 ffffea000417a000 dead000000000002
    raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000
    head: 0017ffffc0000040 ffff888100042f00 ffffea000417a000 dead000000000002
    head: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000
    head: 0017ffffc0000003 ffffea0004d8cc01 ffffffffffffffff 0000000000000000
    head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff888136335280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff888136335300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    >ffff888136335380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
     ffff888136335400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
     ffff888136335480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
    ==================================================================
    
    Fixes: 6827ca573c03 ("memstick: rtsx_usb_ms: Support runtime power management")
    Signed-off-by: Luo Qiu <luoqiu@kylinsec.com.cn>
    Cc: stable@vger.kernel.org
    Link: https://lore.kernel.org/r/4B7BC3E6E291E6F2+20250317101438.25650-1-luoqiu@kylinsec.com.cn
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
net: usb: qmi_wwan: add Telit Cinterion FE990B composition [+ + +]
Author: Fabio Porcedda <fabio.porcedda@gmail.com>
Date:   Thu Feb 27 12:24:39 2025 +0100

    net: usb: qmi_wwan: add Telit Cinterion FE990B composition
    
    commit e8cdd91926aac2c53a23925c538ad4c44be4201f upstream.
    
    Add the following Telit Cinterion FE990B composition:
    0x10b0: rmnet + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) +
            tty (diag) + DPL + QDSS (Qualcomm Debug SubSystem) + adb
    
    usb-devices:
    T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  7 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10b0 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FE990
    S:  SerialNumber=28c2595e
    C:  #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=88(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8a(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none)
    E:  Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
    E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
    Link: https://patch.msgid.link/20250227112441.3653819-2-fabio.porcedda@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: qmi_wwan: add Telit Cinterion FN990B composition [+ + +]
Author: Fabio Porcedda <fabio.porcedda@gmail.com>
Date:   Wed Feb 5 18:16:46 2025 +0100

    net: usb: qmi_wwan: add Telit Cinterion FN990B composition
    
    commit 9dba9a45f8ca64a7df32aada14c20a3153af1ac8 upstream.
    
    Add the following Telit Cinterion FN990B composition:
    
    0x10d0: rmnet + tty (AT/NMEA) + tty (AT) + tty (AT) + tty (AT) +
            tty (diag) + DPL + QDSS (Qualcomm Debug SubSystem) + adb
    T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 17 Spd=480  MxCh= 0
    D:  Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
    P:  Vendor=1bc7 ProdID=10d0 Rev=05.15
    S:  Manufacturer=Telit Cinterion
    S:  Product=FN990
    S:  SerialNumber=43b38f19
    C:  #Ifs= 9 Cfg#= 1 Atr=e0 MxPwr=500mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
    E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=82(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
    I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=60 Driver=option
    E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=88(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
    E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8a(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
    I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
    E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 6 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
    E:  Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 7 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none)
    E:  Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    I:  If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
    E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E:  Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    
    Cc: stable@vger.kernel.org
    Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
    Link: https://patch.msgid.link/20250205171649.618162-3-fabio.porcedda@gmail.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

net: usb: usbnet: restore usb%d name exception for local mac addresses [+ + +]
Author: Dominique Martinet <dominique.martinet@atmark-techno.com>
Date:   Wed Mar 26 17:32:36 2025 +0900

    net: usb: usbnet: restore usb%d name exception for local mac addresses
    
    commit 2ea396448f26d0d7d66224cb56500a6789c7ed07 upstream.
    
    commit 8a7d12d674ac ("net: usb: usbnet: fix name regression") assumed
    that local addresses always came from the kernel, but some devices hand
    out local mac addresses so we ended up with point-to-point devices with
    a mac set by the driver, renaming to eth%d when they used to be named
    usb%d.
    
    Userspace should not rely on device name, but for the sake of stability
    restore the local mac address check portion of the naming exception:
    point to point devices which either have no mac set by the driver or
    have a local mac handed out by the driver will keep the usb%d name.
    
    (some USB LTE modems are known to hand out a stable mac from the locally
    administered range; that mac appears to be random (different for
    mulitple devices) and can be reset with device-specific commands, so
    while such devices would benefit from getting a OUI reserved, we have
    to deal with these and might as well preserve the existing behavior
    to avoid breaking fragile openwrt configurations and such on upgrade.)
    
    Link: https://lkml.kernel.org/r/20241203130457.904325-1-asmadeus@codewreck.org
    Fixes: 8a7d12d674ac ("net: usb: usbnet: fix name regression")
    Cc: stable@vger.kernel.org
    Tested-by: Ahmed Naseef <naseefkm@gmail.com>
    Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
    Acked-by: Oliver Neukum <oneukum@suse.com>
    Link: https://patch.msgid.link/20250326-usbnet_rename-v2-1-57eb21fcff26@atmark-techno.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
netfilter: socket: Lookup orig tuple for IPv6 SNAT [+ + +]
Author: Maxim Mikityanskiy <maxtram95@gmail.com>
Date:   Tue Mar 18 18:15:16 2025 +0200

    netfilter: socket: Lookup orig tuple for IPv6 SNAT
    
    commit 932b32ffd7604fb00b5c57e239a3cc4d901ccf6e upstream.
    
    nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to
    restore the original 5-tuple in case of SNAT, to be able to find the
    right socket (if any). Then socket_match() can correctly check whether
    the socket was transparent.
    
    However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this
    conntrack lookup, making xt_socket fail to match on the socket when the
    packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6.
    
    IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as
    pods' addresses are in the fd00::/8 ULA subnet and need to be replaced
    with the node's external address. Cilium leverages Envoy to enforce L7
    policies, and Envoy uses transparent sockets. Cilium inserts an iptables
    prerouting rule that matches on `-m socket --transparent` and redirects
    the packets to localhost, but it fails to match SNATed IPv6 packets due
    to that missing conntrack lookup.
    
    Closes: https://github.com/cilium/cilium/issues/37932
    Fixes: eb31628e37a0 ("netfilter: nf_tables: Add support for IPv6 NAT")
    Signed-off-by: Maxim Mikityanskiy <maxim@isovalent.com>
    Reviewed-by: Florian Westphal <fw@strlen.de>
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
nfsd: fix legacy client tracking initialization [+ + +]
Author: Scott Mayhew <smayhew@redhat.com>
Date:   Tue Dec 10 07:25:54 2024 -0500

    nfsd: fix legacy client tracking initialization
    
    commit de71d4e211eddb670b285a0ea477a299601ce1ca upstream.
    
    Get rid of the nfsd4_legacy_tracking_ops->init() call in
    check_for_legacy_methods().  That will be handled in the caller
    (nfsd4_client_tracking_init()).  Otherwise, we'll wind up calling
    nfsd4_legacy_tracking_ops->init() twice, and the second time we'll
    trigger the BUG_ON() in nfsd4_init_recdir().
    
    Fixes: 74fd48739d04 ("nfsd: new Kconfig option for legacy client tracking")
    Reported-by: Jur van der Burg <jur@avtware.com>
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=219580
    Signed-off-by: Scott Mayhew <smayhew@redhat.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Tested-by: Salvatore Bonaccorso <carnil@debian.org>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
perf tools: Fix up some comments and code to properly use the event_source bus [+ + +]
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Wed Feb 19 14:40:56 2025 +0100

    perf tools: Fix up some comments and code to properly use the event_source bus
    
    commit 0cced76a0276610e86e8b187c09f0e9ef85b9299 upstream.
    
    In sysfs, the perf events are all located in
    /sys/bus/event_source/devices/ but some places ended up hard-coding the
    location to be at the root of /sys/devices/ which could be very risky as
    you do not exactly know what type of device you are accessing in sysfs
    at that location.
    
    So fix this all up by properly pointing everything at the bus device
    list instead of the root of the sysfs devices/ tree.
    
    Cc: stable <stable@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
    Link: https://lore.kernel.org/r/2025021955-implant-excavator-179d@gregkh
    Signed-off-by: Namhyung Kim <namhyung@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
serial: 8250_dma: terminate correct DMA in tx_dma_flush() [+ + +]
Author: John Keeping <jkeeping@inmusicbrands.com>
Date:   Mon Feb 24 12:18:30 2025 +0000

    serial: 8250_dma: terminate correct DMA in tx_dma_flush()
    
    commit a26503092c75abba70a0be2aa01145ecf90c2a22 upstream.
    
    When flushing transmit side DMA, it is the transmit channel that should
    be terminated, not the receive channel.
    
    Fixes: 9e512eaaf8f40 ("serial: 8250: Fix fifo underflow on flush")
    Cc: stable <stable@kernel.org>
    Reported-by: Wentao Guan <guanwentao@uniontech.com>
    Signed-off-by: John Keeping <jkeeping@inmusicbrands.com>
    Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
    Link: https://lore.kernel.org/r/20250224121831.1429323-1-jkeeping@inmusicbrands.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

serial: stm32: do not deassert RS485 RTS GPIO prematurely [+ + +]
Author: Cheick Traore <cheick.traore@foss.st.com>
Date:   Thu Mar 20 16:25:40 2025 +0100

    serial: stm32: do not deassert RS485 RTS GPIO prematurely
    
    commit 2790ce23951f0c497810c44ad60a126a59c8d84c upstream.
    
    If stm32_usart_start_tx is called with an empty xmit buffer, RTS GPIO
    could be deasserted prematurely, as bytes in TX FIFO are still
    transmitting.
    So this patch remove rts disable when xmit buffer is empty.
    
    Fixes: d7c76716169d ("serial: stm32: Use TC interrupt to deassert GPIO RTS in RS485 mode")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Cheick Traore <cheick.traore@foss.st.com>
    Link: https://lore.kernel.org/r/20250320152540.709091-1-cheick.traore@foss.st.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
tty: serial: 8250: Add Brainboxes XC devices [+ + +]
Author: Cameron Williams <cang1@live.co.uk>
Date:   Mon Mar 10 22:27:10 2025 +0000

    tty: serial: 8250: Add Brainboxes XC devices
    
    commit 5c7e2896481a177bbda41d7850f05a9f5a8aee2b upstream.
    
    These ExpressCard devices use the OxPCIE chip and can be used with
    this driver.
    
    Signed-off-by: Cameron Williams <cang1@live.co.uk>
    Cc: stable <stable@kernel.org>
    Link: https://lore.kernel.org/r/DB7PR02MB3802907A9360F27F6CD67AAFC4D62@DB7PR02MB3802.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: serial: 8250: Add some more device IDs [+ + +]
Author: Cameron Williams <cang1@live.co.uk>
Date:   Sun Feb 23 22:07:38 2025 +0000

    tty: serial: 8250: Add some more device IDs
    
    commit be6a23650908e2f827f2e7839a3fbae41ccb5b63 upstream.
    
    These card IDs got missed the first time around.
    
    Cc: stable <stable@kernel.org>
    Signed-off-by: Cameron Williams <cang1@live.co.uk>
    Link: https://lore.kernel.org/r/DB7PR02MB380295BCC879CCF91315AC38C4C12@DB7PR02MB3802.eurprd02.prod.outlook.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tty: serial: fsl_lpuart: disable transmitter before changing RS485 related registers [+ + +]
Author: Sherry Sun <sherry.sun@nxp.com>
Date:   Wed Mar 12 10:25:03 2025 +0800

    tty: serial: fsl_lpuart: disable transmitter before changing RS485 related registers
    
    commit f5cb528d6441eb860250a2f085773aac4f44085e upstream.
    
    According to the LPUART reference manual, TXRTSE and TXRTSPOL of MODIR
    register only can be changed when the transmitter is disabled.
    So disable the transmitter before changing RS485 related registers and
    re-enable it after the change is done.
    
    Fixes: 67b01837861c ("tty: serial: lpuart: Add RS485 support for 32-bit uart flavour")
    Cc: stable <stable@kernel.org>
    Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
    Reviewed-by: Frank Li <Frank.Li@nxp.com>
    Link: https://lore.kernel.org/r/20250312022503.1342990-1-sherry.sun@nxp.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 
usb: xhci: Apply the link chain quirk on NEC isoc endpoints [+ + +]
Author: Michal Pecio <michal.pecio@gmail.com>
Date:   Thu Mar 6 16:49:52 2025 +0200

    usb: xhci: Apply the link chain quirk on NEC isoc endpoints
    
    commit bb0ba4cb1065e87f9cc75db1fa454e56d0894d01 upstream.
    
    Two clearly different specimens of NEC uPD720200 (one with start/stop
    bug, one without) were seen to cause IOMMU faults after some Missed
    Service Errors. Faulting address is immediately after a transfer ring
    segment and patched dynamic debug messages revealed that the MSE was
    received when waiting for a TD near the end of that segment:
    
    [ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0
    [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]
    [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
    
    It gets even funnier if the next page is a ring segment accessible to
    the HC. Below, it reports MSE in segment at ff1e8000, plows through a
    zero-filled page at ff1e9000 and starts reporting events for TRBs in
    page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
    
    [ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
    [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0
    [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
    [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.
    [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
    [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
    [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
    [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint
    [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31
    [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
    
    At some point completion events change from Isoch Buffer Overrun to
    Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
    
    [ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
    [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
    [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
    [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
    [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
    
    It's possible that data from the isochronous device were written to
    random buffers of pending TDs on other endpoints (either IN or OUT),
    other devices or even other HCs in the same IOMMU domain.
    
    Lastly, an error from a different USB device on another HC. Was it
    caused by the above? I don't know, but it may have been. The disk
    was working without any other issues and generated PCIe traffic to
    starve the NEC of upstream BW and trigger those MSEs. The two HCs
    shared one x1 slot by means of a commercial "PCIe splitter" board.
    
    [ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd
    [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s
    [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00
    [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
    
    Fortunately, it appears that this ridiculous bug is avoided by setting
    the chain bit of Link TRBs on isochronous rings. Other ancient HCs are
    known which also expect the bit to be set and they ignore Link TRBs if
    it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
    
    The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports
    tens of MSEs per second and runs into the bug within seconds. Chaining
    Link TRBs allows the same workload to run for many minutes, many times.
    
    No negative side effects seen in UVC recording and UAC playback with a
    few devices at full speed, high speed and SuperSpeed.
    
    The problem doesn't reproduce on the newer Renesas uPD720201/uPD720202
    and on old Etron EJ168 and VIA VL805 (but the VL805 has other bug).
    
    [shorten line length of log snippets in commit messge -Mathias]
    
    Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
    Cc: stable@vger.kernel.org
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20250306144954.3507700-14-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: xhci: Don't skip on Stopped - Length Invalid [+ + +]
Author: Michal Pecio <michal.pecio@gmail.com>
Date:   Thu Mar 6 16:49:42 2025 +0200

    usb: xhci: Don't skip on Stopped - Length Invalid
    
    commit 58d0a3fab5f4fdc112c16a4c6d382f62097afd1c upstream.
    
    Up until commit d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are
    returned when isoc ring is stopped") in v6.11, the driver didn't skip
    missed isochronous TDs when handling Stoppend and Stopped - Length
    Invalid events. Instead, it erroneously cleared the skip flag, which
    would cause the ring to get stuck, as future events won't match the
    missed TD which is never removed from the queue until it's cancelled.
    
    This buggy logic seems to have been in place substantially unchanged
    since the 3.x series over 10 years ago, which probably speaks first
    and foremost about relative rarity of this case in normal usage, but
    by the spec I see no reason why it shouldn't be possible.
    
    After d56b0b2ab142, TDs are immediately skipped when handling those
    Stopped events. This poses a potential problem in case of Stopped -
    Length Invalid, which occurs either on completed TDs (likely already
    given back) or Link and No-Op TRBs. Such event won't be recognized
    as matching any TD (unless it's the rare Link TRB inside a TD) and
    will result in skipping all pending TDs, giving them back possibly
    before they are done, risking isoc data loss and maybe UAF by HW.
    
    As a compromise, don't skip and don't clear the skip flag on this
    kind of event. Then the next event will skip missed TDs. A downside
    of not handling Stopped - Length Invalid on a Link inside a TD is
    that if the TD is cancelled, its actual length will not be updated
    to account for TRBs (silently) completed before the TD was stopped.
    
    I had no luck producing this sequence of completion events so there
    is no compelling demonstration of any resulting disaster. It may be
    a very rare, obscure condition. The sole motivation for this patch
    is that if such unlikely event does occur, I'd rather risk reporting
    a cancelled partially done isoc frame as empty than gamble with UAF.
    
    This will be fixed more properly by looking at Stopped event's TRB
    pointer when making skipping decisions, but such rework is unlikely
    to be backported to v6.12, which will stay around for a few years.
    
    Fixes: d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are returned when isoc ring is stopped")
    Cc: stable@vger.kernel.org
    Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
    Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
    Link: https://lore.kernel.org/r/20250306144954.3507700-4-mathias.nyman@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>