OESA-2026-2415

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

driver core: platform: use generic driver_override infrastructure

When a driver is probed through __driverattach(), the bus' match() callback is called without the device lock held, thus accessing the driveroverride field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from _driverattach() without the device lock held is intentional. 1

In the Linux kernel, the following vulnerability has been resolved:

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

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 instrumentcopytouser ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in inlinecopytouser ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in copytouser+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]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 34.84.12-0 11/17/2025 Call Trace: <TASK> dumpstacklvl+0xc5/0x110 ../lib/dumpstack.c:120 printaddressdescription ../mm/kasan/report.c:378 [inline] printreport+0xbc/0x260 ../mm/kasan/report.c:482 kasanreport+0xa2/0xe0 ../mm/kasan/report.c:595 checkregioninline ../mm/kasan/generic.c:-1 [inline] kasancheckrange+0x264/0x2c0 ../mm/kasan/generic.c:200 instrumentcopytouser ../include/linux/instrumented.h:129 [inline] inlinecopytouser ../include/linux/uaccess.h:205 [inline] copytouser+0x66/0xa0 ../lib/usercopy.c:26 copytouser ../include/linux/uaccess.h:236 [inline] sevioctldopdhexport+0x3d3/0x7c0 ../drivers/crypto/ccp/sev-dev.c:2347 sevioctl+0x2a2/0x490 ../drivers/crypto/ccp/sev-dev.c:2568 vfsioctl ../fs/ioctl.c:51 [inline] __dosysioctl ../fs/ioctl.c:597 [inline] __sesysioctl+0x11d/0x1b0 ../fs/ioctl.c:583 dosyscallx64 ../arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe0/0x800 ../arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x76/0x7e </TASK>

WARN if the driver says the command succeeded, but the firmware error code says otherwise, as _sevdocmdlocked() is expected to return -EIO on any firwmware error.(CVE-2026-31698)

In the Linux kernel, the following vulnerability has been resolved:

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

When retrieving the PEK CSR, don't attempt to copy the 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 instrumentcopytouser ../include/linux/instrumented.h:129 [inline] BUG: KASAN: slab-out-of-bounds in inlinecopytouser ../include/linux/uaccess.h:205 [inline] BUG: KASAN: slab-out-of-bounds in copytouser+0x66/0xa0 ../lib/usercopy.c:26 Read of size 2084 at addr ffff898144612e20 by task syz.9.219/21405

CPU: 14 UID: 0 PID: 21405 Comm: syz.9.219 Tainted: G U O 7.0.0-smp-DEV #28 PREEMPTLAZY Tainted: [U]=USER, [O]=OOTMODULE Hardware name: Google, Inc. ArcadiaIT80/ArcadiaIT80, BIOS 12.62.0-0 11/19/2025 Call Trace: <TASK> dumpstacklvl+0xc5/0x110 ../lib/dumpstack.c:120 printaddressdescription ../mm/kasan/report.c:378 [inline] printreport+0xbc/0x260 ../mm/kasan/report.c:482 kasanreport+0xa2/0xe0 ../mm/kasan/report.c:595 checkregioninline ../mm/kasan/generic.c:-1 [inline] kasancheckrange+0x264/0x2c0 ../mm/kasan/generic.c:200 instrumentcopytouser ../include/linux/instrumented.h:129 [inline] inlinecopytouser ../include/linux/uaccess.h:205 [inline] copytouser+0x66/0xa0 ../lib/usercopy.c:26 copytouser ../include/linux/uaccess.h:236 [inline] sevioctldopekcsr+0x31f/0x590 ../drivers/crypto/ccp/sev-dev.c:1872 sevioctl+0x3a4/0x490 ../drivers/crypto/ccp/sev-dev.c:2562 vfsioctl ../fs/ioctl.c:51 [inline] __dosysioctl ../fs/ioctl.c:597 [inline] __sesysioctl+0x11d/0x1b0 ../fs/ioctl.c:583 dosyscallx64 ../arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xe0/0x800 ../arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x76/0x7e </TASK>

WARN if the driver says the command succeeded, but the firmware error code says otherwise, as _sevdocmdlocked() is expected to return -EIO on any firwmware error.(CVE-2026-31699)

In the Linux kernel, the following vulnerability has been resolved:

HID: multitouch: Check to ensure report responses match the request

It is possible for a malicious (or clumsy) device to respond to a specific report's feature request using a completely different report ID. This can cause confusion in the HID core resulting in nasty side-effects such as OOB writes.

Add a check to ensure that the report ID in the response, matches the one that was requested. If it doesn't, omit reporting the raw event and return early.(CVE-2026-43047)

In the Linux kernel, the following vulnerability has been resolved:

HID: core: Mitigate potential OOB by removing bogus memset()

The memset() in hidreportraw_event() has the good intention of clearing out bogus data by zeroing the area from the end of the incoming data string to the assumed end of the buffer. However, as we have previously seen, doing so can easily result in OOB reads and writes in the subsequent thread of execution.

The current suggestion from one of the HID maintainers is to remove the memset() and simply return if the incoming event buffer size is not large enough to fill the associated report.

Suggested-by Benjamin Tissoires <(CVE-2026-43048)

In the Linux kernel, the following vulnerability has been resolved:

ptrace: slightly saner 'get_dumpable()' logic

The 'dumpability' of a task is fundamentally about the memory image of the task - the concept comes from whether it can core dump or not - and makes no sense when you don't have an associated mm.

And almost all users do in fact use it only for the case where the task has a mm pointer.

But we have one odd special case: ptracemayaccess() uses 'dumpable' to check various other things entirely independently of the MM (typically explicitly using flags like PTRACEMODEREAD_FSCREDS). Including for threads that no longer have a VM (and maybe never did, like most kernel threads).

It's not what this flag was designed for, but it is what it is.

The ptrace code does check that the uid/gid matches, so you do have to be uid-0 to see kernel thread details, but this means that the traditional "drop capabilities" model doesn't make any difference for this all.

Make it all make a bit more sense by saying that if you don't have a MM pointer, we'll use a cached "last dumpability" flag if the thread ever had a MM (it will be zero for kernel threads since it is never set), and require a proper CAPSYSPTRACE capability to override.(CVE-2026-46333)