laptop-kernel, branch master

firmware_loader: always print path of firmware

2026-05-05T15:25:21Z

This will help me optimize my /etc/portage/savedconfig/sys-kernel/linux-firmware-* file. Signed-off-by: Jason A. Donenfeld

power: supply: avoid nullptr deref in __power_supply_is_system_supplied

2026-05-05T15:25:21Z

Fix the following OOPS: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] PREEMPT SMP CPU: 14 PID: 1156 Comm: upowerd Tainted: G S U 6.0.0-rc1+ #366 Hardware name: LENOVO 20Y5CTO1WW/20Y5CTO1WW, BIOS N40ET36W (1.18 ) 07/19/2022 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffff88815350bd08 EFLAGS: 00010212 RAX: ffff88810207d620 RBX: ffff88815350bd7c RCX: 000000000000394e RDX: ffff88815350bd10 RSI: 0000000000000004 RDI: ffff888111722c00 RBP: ffff88815350bd68 R08: ffff8881187a8af8 R09: ffff8881187a8af8 R10: 0000000000000000 R11: 000000000000005f R12: ffffffff8162d0b0 R13: ffff88810159a038 R14: ffffffff823b3768 R15: ffff88810159a000 FS: 00007fd1f0958140(0000) GS:ffff88901f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000152c7a004 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: __power_supply_is_system_supplied+0x26/0x40 class_for_each_device+0xa5/0xd0 ? acpi_battery_get_state+0x4e/0x1f0 power_supply_is_system_supplied+0x26/0x40 acpi_battery_get_property+0x301/0x310 power_supply_show_property+0xa5/0x1d0 dev_attr_show+0x10/0x30 sysfs_kf_seq_show+0x78/0xc0 seq_read_iter+0xfd/0x3e0 vfs_read+0x1cb/0x290 ksys_read+0x4e/0xc0 do_syscall_64+0x2b/0x50 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fd1f0bed70c Code: ec 28 48 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 a4 f8 ff 41 89 c0 48 8b 54 24 18 48 8b 74 24 10 8b 7c 24 08 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 34 44 89 c7 48 89 44 24 08 e8 8f a4 f8 ff 48 RSP: 002b:00007ffc8d3f27e0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd1f0bed70c RDX: 0000000000001000 RSI: 000055957d534850 RDI: 000000000000000c RBP: 000055957d50b1d0 R08: 0000000000000000 R09: 0000000000001000 R10: 000000000000006f R11: 0000000000000246 R12: 00007ffc8d3f2910 R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000c CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffff88815350bd08 EFLAGS: 00010212 RAX: ffff88810207d620 RBX: ffff88815350bd7c RCX: 000000000000394e RDX: ffff88815350bd10 RSI: 0000000000000004 RDI: ffff888111722c00 RBP: ffff88815350bd68 R08: ffff8881187a8af8 R09: ffff8881187a8af8 R10: 0000000000000000 R11: 000000000000005f R12: ffffffff8162d0b0 R13: ffff88810159a038 R14: ffffffff823b3768 R15: ffff88810159a000 FS: 00007fd1f0958140(0000) GS:ffff88901f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000152c7a004 CR4: 0000000000770ee0 The disassembly of the top function in the stack trace is: .text:0000000000000000 __power_supply_is_system_supplied proc near .text:0000000000000000 ; DATA XREF: power_supply_is_system_supplied+12↓o .text:0000000000000000 .text:0000000000000000 var_8 = qword ptr -8 .text:0000000000000000 .text:0000000000000000 sub rsp, 8 .text:0000000000000004 mov rdi, [rdi+78h] .text:0000000000000008 inc dword ptr [rsi] .text:000000000000000A mov [rsp+8+var_8], 0 .text:0000000000000012 mov rax, [rdi] .text:0000000000000015 cmp dword ptr [rax+8], 1 .text:0000000000000019 jz short loc_2A .text:000000000000001B mov rdx, rsp .text:000000000000001E mov esi, 4 .text:0000000000000023 call qword ptr [rax+30h] .text:0000000000000026 test eax, eax .text:0000000000000028 jz short loc_31 .text:000000000000002A .text:000000000000002A loc_2A: ; CODE XREF: __power_supply_is_system_supplied+19↑j .text:000000000000002A xor eax, eax .text:000000000000002C add rsp, 8 .text:0000000000000030 retn .text:0000000000000031 ; --------------------------------------------------------------------------- .text:0000000000000031 .text:0000000000000031 loc_31: ; CODE XREF: __power_supply_is_system_supplied+28↑j .text:0000000000000031 mov eax, dword ptr [rsp+8+var_8] .text:0000000000000034 add rsp, 8 .text:0000000000000038 retn .text:0000000000000038 __power_supply_is_system_supplied endp So presumably `call qword ptr [rax+30h]` is jumping to NULL. Cc: stable@vger.kernel.org Cc: Rafael J. Wysocki Signed-off-by: Jason A. Donenfeld

x86/split_lock: turn off by default

2026-05-05T15:25:21Z

I don't want the log spam. Signed-off-by: Jason A. Donenfeld

thermal: don't shut off system when melting

2026-05-05T15:25:20Z

Signed-off-by: Jason A. Donenfeld

v4l2: add loopback driver

2026-05-05T15:25:20Z

I've cleaned up the compat stuff for this out of tree driver. Signed-off-by: Jason A. Donenfeld

acpi: import acpi_call driver

2026-05-05T15:25:20Z

This code, from , is garbage, but it's still quite useful, so import it here in a somewhat sane way. Signed-off-by: Jason A. Donenfeld

Linux 7.0.3

2026-04-30T09:13:05Z

Signed-off-by: Greg Kroah-Hartman

xen/privcmd: fix double free via VMA splitting

2026-04-30T09:13:05Z

commit 24daca4fc07f3ff8cd0e3f629cd982187f48436a upstream. privcmd_vm_ops defines .close (privcmd_close), but neither .may_split nor .open. When userspace does a partial munmap() on a privcmd mapping, the kernel splits the VMA via __split_vma(). Since may_split is NULL, the split is allowed. vm_area_dup() copies vm_private_data (a pages array allocated in alloc_empty_pages()) into the new VMA without any fixup, because there is no .open callback. Both VMAs now point to the same pages array. When the unmapped portion is closed, privcmd_close() calls: - xen_unmap_domain_gfn_range() - xen_free_unpopulated_pages() - kvfree(pages) The surviving VMA still holds the dangling pointer. When it is later destroyed, the same sequence runs again, which leads to a double free. Fix this issue by adding a .may_split callback denying the VMA split. This is XSA-487 / CVE-2026-31787 Fixes: d71f513985c2 ("xen: privcmd: support autotranslated physmap guests.") Reported-by: Atharva Vartak Suggested-by: Atharva Vartak Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Signed-off-by: Greg Kroah-Hartman

Buffer overflow in drivers/xen/sys-hypervisor.c

2026-04-30T09:13:05Z

commit 27fdbab4221b375de54bf91919798d88520c6e28 upstream. The build id returned by HYPERVISOR_xen_version(XENVER_build_id) is neither NUL terminated nor a string. The first causes a buffer overflow as sprintf in buildid_show will read and copy till it finds a NUL. 00000000 f4 91 51 f4 dd 38 9e 9d 65 47 52 eb 10 71 db 50 |..Q..8..eGR..q.P| 00000010 b9 a8 01 42 6f 2e 32 |...Bo.2| 00000017 So use a memcpy instead of sprintf to have the correct value: 00000000 f4 91 51 f4 dd 00 9e 9d 65 47 52 eb 10 71 db 50 |..Q.....eGR..q.P| 00000010 b9 a8 01 42 |...B| 00000014 (the above have a hack to embed a zero inside and check it's returned correctly). This is XSA-485 / CVE-2026-31786 Fixes: 84b7625728ea ("xen: add sysfs node for hypervisor build id") Signed-off-by: Frediano Ziglio Reviewed-by: Juergen Gross Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman

Linux 7.0.2

2026-04-27T13:30:19Z

Link: https://lore.kernel.org/r/20260424132420.410310336@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Takeshi Ogasawara Tested-by: Florian Fainelli Tested-by: Mark Brown Tested-by: Peter Schneider Tested-by: Shuah Khan Tested-by: Brett A C Sheffield Tested-by: Miguel Ojeda Tested-by: Ron Economos Tested-by: Dileep Malepu Tested-by: Barry K. Nathan Tested-by: Salvatore Bonaccorso Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman