laptop-kernel/drivers, 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

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

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

mshv_vtl: Fix vmemmap_shift exceeding MAX_FOLIO_ORDER

2026-04-27T13:30:19Z

commit 404cd6bffe17e25e0f94ed2775ffdd6cd10ac3fd upstream. When registering VTL0 memory via MSHV_ADD_VTL0_MEMORY, the kernel computes pgmap->vmemmap_shift as the number of trailing zeros in the OR of start_pfn and last_pfn, intending to use the largest compound page order both endpoints are aligned to. However, this value is not clamped to MAX_FOLIO_ORDER, so a sufficiently aligned range (e.g. physical range [0x800000000000, 0x800080000000), corresponding to start_pfn=0x800000000 with 35 trailing zeros) can produce a shift larger than what memremap_pages() accepts, triggering a WARN and returning -EINVAL: WARNING: ... memremap_pages+0x512/0x650 requested folio size unsupported The MAX_FOLIO_ORDER check was added by commit 646b67d57589 ("mm/memremap: reject unreasonable folio/compound page sizes in memremap_pages()"). Fix this by clamping vmemmap_shift to MAX_FOLIO_ORDER so we always request the largest order the kernel supports, in those cases, rather than an out-of-range value. Also fix the error path to propagate the actual error code from devm_memremap_pages() instead of hard-coding -EFAULT, which was masking the real -EINVAL return. Fixes: 7bfe3b8ea6e3 ("Drivers: hv: Introduce mshv_vtl driver") Cc: stable@vger.kernel.org Signed-off-by: Naman Jain Reviewed-by: Michael Kelley Signed-off-by: Wei Liu Signed-off-by: Greg Kroah-Hartman

crypto: ccp: Don't attempt to copy ID to userspace if PSP command failed

2026-04-27T13:30:19Z

commit 4f685dbfa87c546e51d9dc6cab379d20f275e114 upstream. When retrieving the ID for the CPU, don't attempt to copy the ID blob to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 64 at addr ffff8881867f5960 by task syz.0.906/24388 CPU: 130 UID: 0 PID: 24388 Comm: syz.0.906 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.62.0-0 11/19/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_get_id2+0x361/0x490 ../drivers/crypto/ccp/sev-dev.c:2222 sev_ioctl+0x25f/0x490 ../drivers/crypto/ccp/sev-dev.c:2575 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error. Reported-by: Alexander Potapenko Reported-by: Sebastian Alba Vives Fixes: d6112ea0cb34 ("crypto: ccp - introduce SEV_GET_ID2 command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: ccp: Don't attempt to copy PDH cert to userspace if PSP command failed

2026-04-27T13:30:19Z

commit e76239fed3cffd6d304d8ca3ce23984fd24f57d3 upstream. When retrieving the PDH cert, don't attempt to copy the blobs to userspace if the firmware command failed. If the failure was due to an invalid length, i.e. the userspace buffer+length was too small, copying the number of bytes _firmware_ requires will overflow the kernel-allocated buffer and leak data to userspace. BUG: KASAN: slab-out-of-bounds in instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff8885c4ab8aa0 by task syz.0.186/21033 CPU: 51 UID: 0 PID: 21033 Comm: syz.0.186 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.84.12-0 11/17/2025 Call Trace: dump_stack_lvl+0xc5/0x110 ../lib/dump_stack.c:120 print_address_description ../mm/kasan/report.c:378 [inline] print_report+0xbc/0x260 ../mm/kasan/report.c:482 kasan_report+0xa2/0xe0 ../mm/kasan/report.c:595 check_region_inline ../mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2c0 ../mm/kasan/generic.c:200 instrument_copy_to_user ../include/linux/instrumented.h:129 [inline] _inline_copy_to_user ../include/linux/uaccess.h:205 [inline] _copy_to_user+0x66/0xa0 ../lib/usercopy.c:26 copy_to_user ../include/linux/uaccess.h:236 [inline] sev_ioctl_do_pdh_export+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sev_ioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfs_ioctl ../fs/ioctl.c:51 [inline] __do_sys_ioctl ../fs/ioctl.c:597 [inline] __se_sys_ioctl+0x11d/0x1b0 ../fs/ioctl.c:583 do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe0/0x800 ../arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e WARN if the driver says the command succeeded, but the firmware error code says otherwise, as __sev_do_cmd_locked() is expected to return -EIO on any firwmware error. Reported-by: Alexander Potapenko Reported-by: Sebastian Alba Vives Fixes: 76a2b524a4b1 ("crypto: ccp: Implement SEV_PDH_CERT_EXPORT ioctl command") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman