user/sven/linux.git, branch v6.15.6

Linux 6.15.6

2025-07-10T14:08:55Z

Link: https://lore.kernel.org/r/20250708162236.549307806@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Justin M. Forbes Tested-by: Salvatore Bonaccorso Tested-by: Takeshi Ogasawara Tested-by: Mark Brown Tested-by: Ron Economos Tested-by: Luna Jernberg Tested-by: Jon Hunter Tested-by: Miguel Ojeda Tested-by: Christian Heusel Signed-off-by: Greg Kroah-Hartman

x86/process: Move the buffer clearing before MONITOR

2025-07-10T14:08:55Z

Commit 8e786a85c0a3c0fffae6244733fb576eeabd9dec upstream. Move the VERW clearing before the MONITOR so that VERW doesn't disarm it and the machine never enters C1. Original idea by Kim Phillips . Suggested-by: Andrew Cooper Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Greg Kroah-Hartman

x86/microcode/AMD: Add TSA microcode SHAs

2025-07-10T14:08:55Z

Commit 2329f250e04d3b8e78b36a68b9880ca7750a07ef upstream. Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Greg Kroah-Hartman

KVM: SVM: Advertise TSA CPUID bits to guests

2025-07-10T14:08:55Z

Commit 31272abd5974b38ba312e9cf2ec2f09f9dd7dcba upstream. Synthesize the TSA CPUID feature bits for guests. Set TSA_{SQ,L1}_NO on unaffected machines. Signed-off-by: Borislav Petkov (AMD) Signed-off-by: Greg Kroah-Hartman

KVM: x86: Sort CPUID_8000_0021_EAX leaf bits properly

2025-07-10T14:08:55Z

Commit 49c140d5af127ef4faf19f06a89a0714edf0316f upstream. WRMSR_XX_BASE_NS is bit 1 so put it there, add some new bits as comments only. Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20250324160617.15379-1-bp@kernel.org [sean: skip the FSRS/FSRC placeholders to avoid confusion] Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman

x86/bugs: Add a Transient Scheduler Attacks mitigation

2025-07-10T14:08:54Z

Commit d8010d4ba43e9f790925375a7de100604a5e2dba upstream. Add the required features detection glue to bugs.c et all in order to support the TSA mitigation. Co-developed-by: Kim Phillips Signed-off-by: Kim Phillips Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Pawan Gupta Signed-off-by: Greg Kroah-Hartman

x86/bugs: Rename MDS machinery to something more generic

2025-07-10T14:08:54Z

Commit f9af88a3d384c8b55beb5dc5483e5da0135fadbd upstream. It will be used by other x86 mitigations. No functional changes. Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Pawan Gupta Signed-off-by: Greg Kroah-Hartman

mm/vmalloc: fix data race in show_numa_info()

2025-07-10T14:08:54Z

commit 5c5f0468d172ddec2e333d738d2a1f85402cf0bc upstream. The following data-race was found in show_numa_info(): ================================================================== BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_show read to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 .... write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299 .... value changed: 0x0000008f -> 0x00000000 ================================================================== According to this report,there is a read/write data-race because m->private is accessible to multiple CPUs. To fix this, instead of allocating the heap in proc_vmalloc_init() and passing the heap address to m->private, vmalloc_info_show() should allocate the heap. Link: https://lkml.kernel.org/r/20250508165620.15321-1-aha310510@gmail.com Fixes: 8e1d743f2c26 ("mm: vmalloc: support multiple nodes in vmallocinfo") Signed-off-by: Jeongjun Park Suggested-by: Eric Dumazet Suggested-by: Andrew Morton Reviewed-by: "Uladzislau Rezki (Sony)" Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

usb: typec: displayport: Fix potential deadlock

2025-07-10T14:08:54Z

commit 099cf1fbb8afc3771f408109f62bdec66f85160e upstream. The deadlock can occur due to a recursive lock acquisition of `cros_typec_altmode_data::mutex`. The call chain is as follows: 1. cros_typec_altmode_work() acquires the mutex 2. typec_altmode_vdm() -> dp_altmode_vdm() -> 3. typec_altmode_exit() -> cros_typec_altmode_exit() 4. cros_typec_altmode_exit() attempts to acquire the mutex again To prevent this, defer the `typec_altmode_exit()` call by scheduling it rather than calling it directly from within the mutex-protected context. Cc: stable Fixes: b4b38ffb38c9 ("usb: typec: displayport: Receive DP Status Update NAK request exit dp altmode") Signed-off-by: Andrei Kuchynski Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250624133246.3936737-1-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman

platform/x86: think-lmi: Fix sysfs group cleanup

2025-07-10T14:08:54Z

commit 4f30f946f27b7f044cf8f3f1f353dee1dcd3517a upstream. Many error paths in tlmi_sysfs_init() lead to sysfs groups being removed when they were not even created. Fix this by letting the kobject core manage these groups through their kobj_type's defult_groups. Fixes: a40cd7ef22fb ("platform/x86: think-lmi: Add WMI interface support on Lenovo platforms") Cc: stable@vger.kernel.org Reviewed-by: Mark Pearson Reviewed-by: Ilpo Järvinen Signed-off-by: Kurt Borja Link: https://lore.kernel.org/r/20250630-lmi-fix-v3-3-ce4f81c9c481@gmail.com Signed-off-by: Ilpo Järvinen Signed-off-by: Greg Kroah-Hartman