Author: Shenghao Ding <[email protected]> Date: Mon Sep 8 06:27:27 2025 +0800 ALSA: hda/tas2781: Fix the order of TAS2781 calibrated-data commit 71d2893a235bf3b95baccead27b3d47f2f2cdc4c upstream. A bug reported by one of my customers that the order of TAS2781 calibrated-data is incorrect, the correct way is to move R0_Low and insert it between R0 and InvR0. Fixes: 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") Signed-off-by: Shenghao Ding <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Cc: Gergo Koteles <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Venkata Prasad Potturu <[email protected]> Date: Thu Aug 21 11:15:47 2025 +0530 ASoC: amd: acp: Adjust pdm gain value [ Upstream commit f1d0260362d72f9f454dc1f9db2eeb80cb801f28 ] Set pdm gain value by setting PDM_MISC_CTRL_MASK value. To avoid low pdm gain value. Signed-off-by: Venkata Prasad Potturu <[email protected]> Reviewed-by: Mario Limonciello (AMD) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jack Yu <[email protected]> Date: Wed Sep 17 08:11:43 2025 +0000 ASoC: rt5682s: Adjust SAR ADC button mode to fix noise issue [ Upstream commit 1dd28fd86c3fa4e395031dd6f2ba920242107010 ] Adjust register settings for SAR adc button detection mode to fix noise issue in headset. Signed-off-by: Jack Yu <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuming Fan <[email protected]> Date: Mon Sep 1 16:57:57 2025 +0800 ASoC: rt712: avoid skipping the blind write [ Upstream commit f54d87dad7619c8026e95b848d6ef677b9f2b55f ] Some devices might not use the DMIC function of the RT712VB. Therefore, this patch avoids skipping the blind write with RT712VB. Signed-off-by: Shuming Fan <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Carlos Llamas <[email protected]> Date: Mon Sep 15 22:12:47 2025 +0000 binder: fix double-free in dbitmap commit 3ebcd3460cad351f198c39c6edb4af519a0ed934 upstream. A process might fail to allocate a new bitmap when trying to expand its proc->dmap. In that case, dbitmap_grow() fails and frees the old bitmap via dbitmap_free(). However, the driver calls dbitmap_free() again when the same process terminates, leading to a double-free error: ================================================================== BUG: KASAN: double-free in binder_proc_dec_tmpref+0x2e0/0x55c Free of addr ffff00000b7c1420 by task kworker/9:1/209 CPU: 9 UID: 0 PID: 209 Comm: kworker/9:1 Not tainted 6.17.0-rc6-dirty #5 PREEMPT Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: kfree+0x164/0x31c binder_proc_dec_tmpref+0x2e0/0x55c binder_deferred_func+0xc24/0x1120 process_one_work+0x520/0xba4 [...] Allocated by task 448: __kmalloc_noprof+0x178/0x3c0 bitmap_zalloc+0x24/0x30 binder_open+0x14c/0xc10 [...] Freed by task 449: kfree+0x184/0x31c binder_inc_ref_for_node+0xb44/0xe44 binder_transaction+0x29b4/0x7fbc binder_thread_write+0x1708/0x442c binder_ioctl+0x1b50/0x2900 [...] ================================================================== Fix this issue by marking proc->map NULL in dbitmap_free(). Cc: [email protected] Fixes: 15d9da3f818c ("binder: use bitmap for faster descriptor lookup") Signed-off-by: Carlos Llamas <[email protected]> Reviewed-by: Alice Ryhl <[email protected]> Reviewed-by: Tiffany Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zenm Chen <[email protected]> Date: Sat Jul 26 00:14:32 2025 +0800 Bluetooth: btusb: Add USB ID 2001:332a for D-Link AX9U rev. A1 commit 34ecb8760190606472f71ebf4ca2817928ce5d40 upstream. Add USB ID 2001:332a for D-Link AX9U rev. A1 which is based on a Realtek RTL8851BU chip. The information in /sys/kernel/debug/usb/devices about the Bluetooth device is listed as the below: T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2001 ProdID=332a Rev= 0.00 S: Manufacturer=Realtek S: Product=802.11ax WLAN Adapter S: SerialNumber=00e04c000001 C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01 I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms I: If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 63 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 63 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 8 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtw89_8851bu_git E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=09(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Cc: [email protected] # 6.12.x Signed-off-by: Zenm Chen <[email protected]> Reviewed-by: Paul Menzel <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Sterba <[email protected]> Date: Mon Sep 15 08:37:47 2025 +0200 btrfs: ref-verify: handle damaged extent root tree [ Upstream commit ed4e6b5d644c4dd2bc2872ffec036b7da0ec2e27 ] Syzbot hits a problem with enabled ref-verify, ignorebadroots and a fuzzed/damaged extent tree. There's no fallback option like in other places that can deal with it so disable the whole ref-verify as it is just a debugging feature. Reported-by: [email protected] Link: https://lore.kernel.org/all/[email protected]/ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chen Yufeng <[email protected]> Date: Thu Sep 11 23:08:20 2025 +0800 can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled [ Upstream commit 6b696808472197b77b888f50bc789a3bae077743 ] This issue is similar to the vulnerability in the `mcp251x` driver, which was fixed in commit 03c427147b2d ("can: mcp251x: fix resume from sleep before interface was brought up"). In the `hi311x` driver, when the device resumes from sleep, the driver schedules `priv->restart_work`. However, if the network interface was not previously enabled, the `priv->wq` (workqueue) is not allocated and initialized, leading to a null pointer dereference. To fix this, we move the allocation and initialization of the workqueue from the `hi3110_open` function to the `hi3110_can_probe` function. This ensures that the workqueue is properly initialized before it is used during device resume. And added logic to destroy the workqueue in the error handling paths of `hi3110_can_probe` and in the `hi3110_can_remove` function to prevent resource leaks. Signed-off-by: Chen Yufeng <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Duy Nguyen <[email protected]> Date: Thu Sep 18 07:03:45 2025 +0000 can: rcar_canfd: Fix controller mode setting [ Upstream commit 5cff263606a10102a0ea19ff579eaa18fd5577ad ] Driver configures register to choose controller mode before setting all channels to reset mode leading to failure. The patch corrects operation of mode setting. Signed-off-by: Duy Nguyen <[email protected]> Signed-off-by: Tranh Ha <[email protected]> Link: https://patch.msgid.link/TYWPR01MB87434739F83E27EDCD23DF44B416A@TYWPR01MB8743.jpnprd01.prod.outlook.com Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Thu Oct 2 17:45:39 2025 +0800 crypto: rng - Ensure set_ent is always present commit c0d36727bf39bb16ef0a67ed608e279535ebf0da upstream. Ensure that set_ent is always set since only drbg provides it. Fixes: 77ebdabe8de7 ("crypto: af_alg - add extra parameters for DRBG interface") Reported-by: Yiqi Sun <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Mikulas Patocka <[email protected]> Date: Mon Sep 8 15:52:02 2025 +0200 dm-integrity: limit MAX_TAG_SIZE to 255 [ Upstream commit 77b8e6fbf9848d651f5cb7508f18ad0971f3ffdb ] MAX_TAG_SIZE was 0x1a8 and it may be truncated in the "bi->metadata_size = ic->tag_size" assignment. We need to limit it to 255. Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Thu Aug 28 12:59:24 2025 +0200 driver core/PM: Set power.no_callbacks along with power.no_pm commit c2ce2453413d429e302659abc5ace634e873f6f5 upstream. Devices with power.no_pm set are not expected to need any power management at all, so modify device_set_pm_not_required() to set power.no_callbacks for them too in case runtime PM will be enabled for any of them (which in principle may be done for convenience if such a device participates in a dependency chain). Since device_set_pm_not_required() must be called before device_add() or it would not have any effect, it can update power.no_callbacks without locking, unlike pm_runtime_no_callbacks() that can be called after registering the target device. Signed-off-by: Rafael J. Wysocki <[email protected]> Cc: stable <[email protected]> Reviewed-by: Sudeep Holla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rafael J. Wysocki <[email protected]> Date: Thu Aug 28 12:56:41 2025 +0200 driver core: faux: Set power.no_pm for faux devices commit 1ad926459970444af1140f9b393f416536e1a828 upstream. Since faux devices are not supposed to be involved in any kind of power management, set the no_pm flag for all of them. Signed-off-by: Rafael J. Wysocki <[email protected]> Cc: stable <[email protected]> Reviewed-by: Sudeep Holla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Max Kellermann <[email protected]> Date: Fri Aug 29 11:14:41 2025 +0200 drivers/misc/amd-sbi/Kconfig: select REGMAP_I2C commit 5f8f84e286f11af4c954c14a57daffc80a1c3510 upstream. Without CONFIG_REGMAP, rmi-i2c.c fails to build because struct regmap_config is not defined: drivers/misc/amd-sbi/rmi-i2c.c: In function ‘sbrmi_i2c_probe’: drivers/misc/amd-sbi/rmi-i2c.c:57:16: error: variable ‘sbrmi_i2c_regmap_config’ has initializer but incomplete type 57 | struct regmap_config sbrmi_i2c_regmap_config = { | ^~~~~~~~~~~~~ Additionally, CONFIG_REGMAP_I2C is needed for devm_regmap_init_i2c(): ld: drivers/misc/amd-sbi/rmi-i2c.o: in function `sbrmi_i2c_probe': drivers/misc/amd-sbi/rmi-i2c.c:69:(.text+0x1c0): undefined reference to `__devm_regmap_init_i2c' Fixes: 013f7e7131bd ("misc: amd-sbi: Use regmap subsystem") Cc: [email protected] Signed-off-by: Max Kellermann <[email protected]> Tested-by: Akshay Gupta <[email protected]> Reviewed-by: Akshay Gupta <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Srinivasan Shanmugam <[email protected]> Date: Wed Sep 10 12:27:05 2025 +0530 drm/amdgpu/gfx11: Add Cleaner Shader Support for GFX11.0.1/11.0.4 GPUs [ Upstream commit c1b6b8c7706354b73196649c46b5e6d4d61c2f5c ] Enable the cleaner shader for additional GFX11.0.1/11.0.4 series GPUs to ensure data isolation among GPU tasks. The cleaner shader is tasked with clearing the Local Data Store (LDS), Vector General Purpose Registers (VGPRs), and Scalar General Purpose Registers (SGPRs), which helps avoid data leakage and guarantees the accuracy of computational results. This update extends cleaner shader support to GFX11.0.1/11.0.4 GPUs, previously available for GFX11.0.3. It enhances security by clearing GPU memory between processes and maintains a consistent GPU state across KGD and KFD workloads. Cc: Wasee Alam <[email protected]> Cc: Mario Sopena-Novales <[email protected]> Cc: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Signed-off-by: Srinivasan Shanmugam <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> (cherry picked from commit 0a71ceb27f88a944c2de2808b67b2f46ac75076b) Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Thu Sep 18 19:48:00 2025 -0500 drm/amdgpu: Enable MES lr_compute_wa by default commit 1fb710793ce2619223adffaf981b1ff13cd48f17 upstream. The MES set resources packet has an optional bit 'lr_compute_wa' which can be used for preventing MES hangs on long compute jobs. Set this bit by default. Co-developed-by: Yifan Zhang <[email protected]> Signed-off-by: Yifan Zhang <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Antheas Kapenekakis <[email protected]> Date: Wed Aug 27 19:58:42 2025 +0200 gpiolib: acpi: Ignore touchpad wakeup on GPD G1619-05 [ Upstream commit 3712ce9fa501617cdc4466d30ae3894d50887743 ] Same issue as G1619-04 in commit 805c74eac8cb ("gpiolib: acpi: Ignore touchpad wakeup on GPD G1619-04"), Strix Point lineup uses 05. Signed-off-by: Antheas Kapenekakis <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Reviewed-by: Mario Limonciello <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaud Lecomte <[email protected]> Date: Sat Jul 26 23:09:31 2025 +0100 hid: fix I2C read buffer overflow in raw_event() for mcp2221 commit b56cc41a3ae7323aa3c6165f93c32e020538b6d2 upstream. As reported by syzbot, mcp2221_raw_event lacked validation of incoming I2C read data sizes, risking buffer overflows in mcp->rxbuf during multi-part transfers. As highlighted in the DS20005565B spec, p44, we have: "The number of read-back data bytes to follow in this packet: from 0 to a maximum of 60 bytes of read-back bytes." This patch enforces we don't exceed this limit. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=52c1a7d3e5b361ccd346 Tested-by: [email protected] Signed-off-by: Arnaud Lecomte <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Romain Sioen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Wed Sep 17 15:59:59 2025 -0300 iommufd: WARN if an object is aborted with an elevated refcount [ Upstream commit 53d0584eeb2c85a46c83656246d61a89558d74b3 ] If something holds a refcount then it is at risk of UAFing. For abort paths we expect the caller to never share the object with a parallel thread and to clean up any refcounts it obtained on its own. Add the missing dec inside iommufd_hwpt_paging_alloc() during error unwind by making iommufd_hw_pagetable_attach/detach() proper pairs. Link: https://patch.msgid.link/r/[email protected] Reviewed-by: Kevin Tian <[email protected]> Reviewed-by: Nicolin Chen <[email protected]> Tested-by: Nicolin Chen <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Tue Jul 15 12:06:38 2025 -0700 KVM: x86: Don't (re)check L1 intercepts when completing userspace I/O commit e750f85391286a4c8100275516973324b621a269 upstream. When completing emulation of instruction that generated a userspace exit for I/O, don't recheck L1 intercepts as KVM has already finished that phase of instruction execution, i.e. has already committed to allowing L2 to perform I/O. If L1 (or host userspace) modifies the I/O permission bitmaps during the exit to userspace, KVM will treat the access as being intercepted despite already having emulated the I/O access. Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation. Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (the intended "recipient") can reach the code in question. gp_interception()'s use is mutually exclusive with is_guest_mode(), and complete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE with EMULTYPE_SKIP. The bad behavior was detected by a syzkaller program that toggles port I/O interception during the userspace I/O exit, ultimately resulting in a WARN on vcpu->arch.pio.count being non-zero due to KVM no completing emulation of the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: <TASK> kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK> Reported-by: [email protected] Closes: https://lore.kernel.org/all/[email protected] Fixes: 8a76d7f25f8f ("KVM: x86: Add x86 callback for intercept check") Cc: [email protected] Cc: Jim Mattson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Sun Oct 12 13:01:05 2025 +0200 Linux 6.16.12 Link: https://lore.kernel.org/r/[email protected] Tested-by: Jon Hunter <[email protected]> Tested-by: Markus Reichelt <[email protected]> Tested-by: Justin M. Forbes <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Mark Brown <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Salvatore Bonaccorso <[email protected]> Tested-by: Brett A C Sheffield <[email protected]> Tested-by: Peter Schneider <[email protected]> Tested-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nalivayko Sergey <[email protected]> Date: Tue Jul 15 18:48:15 2025 +0300 net/9p: fix double req put in p9_fd_cancelled commit 674b56aa57f9379854cb6798c3bbcef7e7b51ab7 upstream. Syzkaller reports a KASAN issue as below: general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f] CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:__list_del include/linux/list.h:114 [inline] RIP: 0010:__list_del_entry include/linux/list.h:137 [inline] RIP: 0010:list_del include/linux/list.h:148 [inline] RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734 Call Trace: <TASK> p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 This happens because of a race condition between: - The 9p client sending an invalid flush request and later cleaning it up; - The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ... Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list in p9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystem client where the req_list could be deleted simultaneously by both p9_read_work and p9_fd_cancelled functions, but for the case where req->status equals REQ_STATUS_RCVD. Update the check for req->status in p9_fd_cancelled to skip processing not just received requests, but anything that is not SENT, as whatever changed the state from SENT also removed the request from its list. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: afd8d6541155 ("9P: Add cancelled() to the transport functions.") Cc: [email protected] Signed-off-by: Nalivayko Sergey <[email protected]> Message-ID: <[email protected]> [updated the check from status == RECV || status == ERROR to status != SENT] Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lizhi Xu <[email protected]> Date: Fri Sep 5 09:59:25 2025 +0800 netfs: Prevent duplicate unlocking [ Upstream commit 66d938e89e940e512f4c3deac938ecef399c13f9 ] The filio lock has been released here, so there is no need to jump to error_folio_unlock to release it again. Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=b73c7d94a151e2ee1e9b Signed-off-by: Lizhi Xu <[email protected]> Acked-by: David Howells <[email protected]> Reviewed-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Walle <[email protected]> Date: Fri Sep 12 14:13:47 2025 +0100 nvmem: layouts: fix automatic module loading commit 810b790033ccc795d55cbef3927668fd01efdfdf upstream. To support loading of a layout module automatically the MODALIAS variable in the uevent is needed. Add it. Fixes: fc29fd821d9a ("nvmem: core: Rework layouts to become regular devices") Cc: [email protected] Signed-off-by: Michael Walle <[email protected]> Reviewed-by: Miquel Raynal <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: hupu <[email protected]> Date: Wed Sep 10 16:16:55 2025 +0800 perf subcmd: avoid crash in exclude_cmds when excludes is empty [ Upstream commit a5edf3550f4260504b7e0ab3d40d13ffe924b773 ] When cross-compiling the perf tool for ARM64, `perf help` may crash with the following assertion failure: help.c:122: exclude_cmds: Assertion `cmds->names[ci] == NULL' failed. This happens when the perf binary is not named exactly "perf" or when multiple "perf-*" binaries exist in the same directory. In such cases, the `excludes` command list can be empty, which leads to the final assertion in exclude_cmds() being triggered. Add a simple guard at the beginning of exclude_cmds() to return early if excludes->cnt is zero, preventing the crash. Signed-off-by: hupu <[email protected]> Reported-by: Guilherme Amadio <[email protected]> Reviewed-by: Namhyung Kim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Namhyung Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: aprilgrimoire <[email protected]> Date: Sun Sep 7 09:06:11 2025 +0000 platform/x86/amd/pmc: Add MECHREVO Yilong15Pro to spurious_8042 list [ Upstream commit 8822e8be86d40410ddd2ac8ff44f3050c9ecf9c6 ] The firmware of Mechrevo Yilong15Pro emits a spurious keyboard interrupt on events including closing the lid. When a user closes the lid on an already suspended system this causes the system to wake up. Add Mechrevo Yilong15Pro Series (GM5HG7A) to the list of quirk spurious_8042 to work around this issue. Link: https://lore.kernel.org/linux-pm/6ww4uu6Gl4F5n6VY5dl1ufASfKzs4DhMxAN8BuqUpCoqU3PQukVSVSBCl_lKIzkQ-S8kt1acPd58eyolhkWN32lMLFj4ViI0Tdu2jwhnYZ8=@proton.me/ Signed-off-by: April Grimoire <[email protected]> Reviewed-by: Mario Limonciello (AMD) <[email protected]> Link: https://patch.msgid.link/IvSc_IN5Pa0wRXElTk_fEl-cTpMZxg6TCQk_7aRUkTd9vJUp_ZeC0NdXZ0z6Tn7B-XiqqqQvCH65lq6FqhuECBMEYWcHQmWm1Jo7Br8kpeg=@proton.me Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoffer Sandberg <[email protected]> Date: Tue Sep 16 18:46:49 2025 +0200 platform/x86/amd/pmc: Add Stellaris Slim Gen6 AMD to spurious 8042 quirks list [ Upstream commit 12a3dd4d2cd9232d4e4df3b9a5b3d745db559941 ] Prevents instant wakeup ~1s after suspend Signed-off-by: Christoffer Sandberg <[email protected]> Signed-off-by: Werner Sembach <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shyam Sundar S K <[email protected]> Date: Mon Sep 15 14:35:46 2025 +0530 platform/x86/amd/pmf: Support new ACPI ID AMDI0108 [ Upstream commit 1b09d08866277677d11726116f5e786d5ba00173 ] Include the ACPI ID AMDI0108, which is used on upcoming AMD platforms, in the PMF driver's list of supported devices. Signed-off-by: Shyam Sundar S K <[email protected]> Reviewed-by: Mario Limonciello (AMD) <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Antheas Kapenekakis <[email protected]> Date: Thu Sep 4 15:22:51 2025 +0200 platform/x86: oxpec: Add support for OneXPlayer X1Pro EVA-02 [ Upstream commit fba9d5448bd45b0ff7199c47023e9308ea4f1730 ] It is a special edition of X1Pro with a different color. Signed-off-by: Antheas Kapenekakis <[email protected]> Link: https://patch.msgid.link/[email protected] Reviewed-by: Ilpo Järvinen <[email protected]> Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ankit Khushwaha <[email protected]> Date: Wed Oct 8 22:55:16 2025 +0530 ring buffer: Propagate __rb_map_vma return value to caller commit de4cbd704731778a2dc833ce5a24b38e5d672c05 upstream. The return value from `__rb_map_vma()`, which rejects writable or executable mappings (VM_WRITE, VM_EXEC, or !VM_MAYSHARE), was being ignored. As a result the caller of `__rb_map_vma` always returned 0 even when the mapping had actually failed, allowing it to proceed with an invalid VMA. Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Link: https://lore.kernel.org/[email protected] Fixes: 117c39200d9d7 ("ring-buffer: Introducing ring-buffer mapping functions") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?id=194151be8eaebd826005329b2e123aecae714bdb Signed-off-by: Ankit Khushwaha <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miguel Ojeda <[email protected]> Date: Wed Jul 30 15:07:14 2025 +0200 rust: block: fix `srctree/` links commit 208d7f788e84e80992d7b1c82ff17b620eb1371e upstream. This `srctree/` link pointed to a file with an underscore, but the header used a dash instead. Thus fix it. This cleans a future warning that will check our `srctree/` links. Cc: [email protected] Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Reviewed-by: Daniel Almeida <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Miguel Ojeda <[email protected]> Date: Wed Jul 30 15:07:15 2025 +0200 rust: drm: fix `srctree/` links commit c2783c7cfefd55b1a5be781679cbee5191c0fd87 upstream. These `srctree/` links pointed inside `linux/`, but they are directly under `drm/`. Thus fix them. This cleans a future warning that will check our `srctree/` links. Cc: [email protected] Fixes: a98a73be9ee9 ("rust: drm: file: Add File abstraction") Fixes: c284d3e42338 ("rust: drm: gem: Add GEM object abstraction") Fixes: 07c9016085f9 ("rust: drm: add driver abstractions") Fixes: 1e4b8896c0f3 ("rust: drm: add device abstraction") Fixes: 9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction") Acked-by: Danilo Krummrich <[email protected]> Reviewed-by: Daniel Almeida <[email protected]> Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rahul Rameshbabu <[email protected]> Date: Sun Sep 14 03:18:34 2025 +0000 rust: pci: fix incorrect platform reference in PCI driver probe doc comment commit 855318e7c0c4a3e3014c0469dd5bc93a1c0df30c upstream. Substitute 'platform' with 'pci'. Fixes: 1bd8b6b2c5d3 ("rust: pci: add basic PCI device / driver abstractions") Cc: [email protected] Signed-off-by: Rahul Rameshbabu <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Raphael Gallais-Pou <[email protected]> Date: Fri Aug 22 16:19:23 2025 +0200 serial: stm32: allow selecting console when the driver is module commit cc4d900d0d6d8dd5c41832a93ff3cfa629a78f9a upstream. Console can be enabled on the UART compile as module. Change dependency to allow console mode when the driver is built as module. Fixes: 48a6092fb41fa ("serial: stm32-usart: Add STM32 USART Driver") Cc: [email protected] Signed-off-by: Raphael Gallais-Pou <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ovidiu Panait <[email protected]> Date: Sun Aug 17 20:13:50 2025 +0300 staging: axis-fifo: fix maximum TX packet length check commit 52ff2b840bc723f3be1f096f8017c78e0515858c upstream. Since commit 2ca34b508774 ("staging: axis-fifo: Correct handling of tx_fifo_depth for size validation"), write() operations with packets larger than 'tx_fifo_depth - 4' words are no longer rejected with -EINVAL. Fortunately, the packets are not actually getting transmitted to hardware, otherwise they would be raising a 'Transmit Packet Overrun Error' interrupt, which requires a reset of the TX circuit to recover from. Instead, the request times out inside wait_event_interruptible_timeout() and always returns -EAGAIN, since the wake up condition can never be true for these packets. But still, they unnecessarily block other tasks from writing to the FIFO and the EAGAIN return code signals userspace to retry the write() call, even though it will always fail and time out. According to the AXI4-Stream FIFO reference manual (PG080), the maximum valid packet length is 'tx_fifo_depth - 4' words, so attempting to send larger packets is invalid and should not be happening in the first place: > The maximum packet that can be transmitted is limited by the size of > the FIFO, which is (C_TX_FIFO_DEPTH–4)*(data interface width/8) bytes. Therefore, bring back the old behavior and outright reject packets larger than 'tx_fifo_depth - 4' with -EINVAL. Add a comment to explain why the check is necessary. The dev_err() message was removed to avoid cluttering the dmesg log if an invalid packet is received from userspace. Fixes: 2ca34b508774 ("staging: axis-fifo: Correct handling of tx_fifo_depth for size validation") Cc: [email protected] Signed-off-by: Ovidiu Panait <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ovidiu Panait <[email protected]> Date: Fri Sep 12 13:13:21 2025 +0300 staging: axis-fifo: fix TX handling on copy_from_user() failure commit 6d07bee10e4bdd043ec7152cbbb9deb27033c9e2 upstream. If copy_from_user() fails, write() currently returns -EFAULT, but any partially written data leaves the TX FIFO in an inconsistent state. Subsequent write() calls then fail with "transmit length mismatch" errors. Once partial data is written to the hardware FIFO, it cannot be removed without a TX reset. Commit c6e8d85fafa7 ("staging: axis-fifo: Remove hardware resets for user errors") removed a full FIFO reset for this case, which fixed a potential RX data loss, but introduced this TX issue. Fix this by introducing a bounce buffer: copy the full packet from userspace first, and write to the hardware FIFO only if the copy was successful. Fixes: c6e8d85fafa7 ("staging: axis-fifo: Remove hardware resets for user errors") Cc: [email protected] Signed-off-by: Ovidiu Panait <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ovidiu Panait <[email protected]> Date: Fri Sep 12 13:13:22 2025 +0300 staging: axis-fifo: flush RX FIFO on read errors commit 82a051e2553b9e297cba82a975d9c538b882c79e upstream. Flush stale data from the RX FIFO in case of errors, to avoid reading old data when new packets arrive. Commit c6e8d85fafa7 ("staging: axis-fifo: Remove hardware resets for user errors") removed full FIFO resets from the read error paths, which fixed potential TX data losses, but introduced this RX issue. Fixes: c6e8d85fafa7 ("staging: axis-fifo: Remove hardware resets for user errors") Cc: [email protected] Signed-off-by: Ovidiu Panait <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiaowei Li <[email protected]> Date: Wed Sep 24 11:16:50 2025 +0800 USB: serial: option: add SIMCom 8230C compositions commit 0e0ba0ecec3d6e819e0c2348331ff99afe2eb5d5 upstream. Add support for SIMCom 8230C which is based on Qualcomm SDX35 chip. USB Device Listings: 0x9071: tty (DM) + tty (NMEA) + tty (AT) + rmnet (QMI mode) + adb T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1e0e ProdID=9071 Rev= 5.15 S: Manufacturer=SIMCOM S: Product=SDXBAAGHA-IDP _SN:D744C4C5 S: SerialNumber=0123456789ABCDEF C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan E: Ad=86(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0x9078: tty (DM) + tty (NMEA) + tty (AT) + ECM + adb T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 9 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1e0e ProdID=9078 Rev= 5.15 S: Manufacturer=SIMCOM S: Product=SDXBAAGHA-IDP _SN:D744C4C5 S: SerialNumber=0123456789ABCDEF C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether E: Ad=86(I) Atr=03(Int.) MxPS= 16 Ivl=32ms I: If#= 4 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether I:* If#= 4 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms 0x907b: RNDIS + tty (DM) + tty (NMEA) + tty (AT) + adb T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 8 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1e0e ProdID=907b Rev= 5.15 S: Manufacturer=SIMCOM S: Product=SDXBAAGHA-IDP _SN:D744C4C5 S: SerialNumber=0123456789ABCDEF C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=ef(misc ) Sub=04 Prot=01 I:* If#= 0 Alt= 0 #EPs= 1 Cls=ef(misc ) Sub=04 Prot=01 Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Xiaowei Li <[email protected]> Cc: [email protected] Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bitterblue Smith <[email protected]> Date: Mon Aug 11 18:33:28 2025 +0300 wifi: rtl8xxxu: Don't claim USB ID 07b8:8188 commit ec0b44736b1d22b763ee94f1aee856f9e793f3fe upstream. This ID appears to be RTL8188SU, not RTL8188CU. This is the wrong driver for RTL8188SU. The r8712u driver from staging used to handle this ID. Closes: https://lore.kernel.org/linux-wireless/[email protected]/ Cc: [email protected] Signed-off-by: Bitterblue Smith <[email protected]> Reviewed-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bitterblue Smith <[email protected]> Date: Mon Aug 11 18:32:55 2025 +0300 wifi: rtlwifi: rtl8192cu: Don't claim USB ID 07b8:8188 commit e798f2ac6040f46a04795d7de977341fa9aeabae upstream. This ID appears to be RTL8188SU, not RTL8188CU. This is the wrong driver for RTL8188SU. The r8712u driver from staging used to handle this ID. Closes: https://lore.kernel.org/linux-wireless/[email protected]/ Cc: [email protected] Signed-off-by: Bitterblue Smith <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Fedor Pchelkin <[email protected]> Date: Fri Oct 3 11:20:05 2025 -0400 wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait() [ Upstream commit 3e31a6bc07312b448fad3b45de578471f86f0e77 ] There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to access already freed skb_data: BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025 Workqueue: events_unbound cfg80211_wiphy_work [cfg80211] Use-after-free write at 0x0000000020309d9d (in kfence-#251): rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago): __alloc_skb net/core/skbuff.c:659 __netdev_alloc_skb net/core/skbuff.c:734 ieee80211_nullfunc_get net/mac80211/tx.c:5844 rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431 rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338 rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979 rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165 rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194 rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012 rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059 rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758 process_one_work kernel/workqueue.c:3241 worker_thread kernel/workqueue.c:3400 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago): ieee80211_tx_status_skb net/mac80211/status.c:1117 rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564 rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651 rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676 rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238 __napi_poll net/core/dev.c:7495 net_rx_action net/core/dev.c:7557 net/core/dev.c:7684 handle_softirqs kernel/softirq.c:580 do_softirq.part.0 kernel/softirq.c:480 __local_bh_enable_ip kernel/softirq.c:407 rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927 irq_thread_fn kernel/irq/manage.c:1133 irq_thread kernel/irq/manage.c:1257 kthread kernel/kthread.c:463 ret_from_fork arch/x86/kernel/process.c:154 ret_from_fork_asm arch/x86/entry/entry_64.S:258 It is a consequence of a race between the waiting and the signaling side of the completion: Waiting thread Completing thread rtw89_core_tx_kick_off_and_wait() rcu_assign_pointer(skb_data->wait, wait) /* start waiting */ wait_for_completion_timeout() rtw89_pci_tx_status() rtw89_core_tx_wait_complete() rcu_read_lock() /* signals completion and * proceeds further */ complete(&wait->completion) rcu_read_unlock() ... /* frees skb_data */ ieee80211_tx_status_ni() /* returns (exit status doesn't matter) */ wait_for_completion_timeout() ... /* accesses the already freed skb_data */ rcu_assign_pointer(skb_data->wait, NULL) The completing side might proceed and free the underlying skb even before the waiting side is fully awoken and run to execution. Actually the race happens regardless of wait_for_completion_timeout() exit status, e.g. the waiting side may hit a timeout and the concurrent completing side is still able to free the skb. Skbs which are sent by rtw89_core_tx_kick_off_and_wait() are owned by the driver. They don't come from core ieee80211 stack so no need to pass them to ieee80211_tx_status_ni() on completing side. Introduce a work function which will act as a garbage collector for rtw89_tx_wait_info objects and the associated skbs. Thus no potentially heavy locks are required on the completing side. Found by Linux Verification Center (linuxtesting.org). Fixes: 1ae5ca615285 ("wifi: rtw89: add function to wait for completion of TX skbs") Cc: [email protected] Suggested-by: Zong-Zhe Yang <[email protected]> Signed-off-by: Fedor Pchelkin <[email protected]> Acked-by: Ping-Ke Shih <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chih-Kang Chang <[email protected]> Date: Fri Oct 3 11:20:04 2025 -0400 wifi: rtw89: mcc: stop TX during MCC prepare [ Upstream commit 182c7ff8b87e4edbb2227ede39ae0952da7a0f4a ] Stop TX during the MCC configuration period to prevent packet leakage. The stop time is defined as 'start_tsf - tsf', which means the duration from when MCC configuration begins until MCC starts. Signed-off-by: Chih-Kang Chang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://patch.msgid.link/[email protected] Stable-dep-of: 3e31a6bc0731 ("wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()") Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>