OESA-2026-3205

The Linux Kernel, the operating system core itself.

Security Fix(es):

Arm C1-Ultra, C1-Premium, Neoverse V3 & V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 & X1C, Cortex-A710, Cortex-A78, A78AE & A78C, Cortex-A77, Cortex-A76 & A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)

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

ALSA: ac97: fix a double free in sndac97controller_register()

If ac97addadapter() fails, putdevice() is the correct way to drop the device reference. kfree() is not required. Add kfree() if idralloc() fails and in ac97adapterrelease() to do the cleanup.

Found by code review.(CVE-2025-71192)

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

can: emsusb: emsusbreadbulk_callback(): fix URB memory leak

Fix similar memory leak as in commit 7352e1d5932a ("can: gsusb: gsusbreceivebulk_callback(): fix URB memory leak").

In emsusbopen(), the URBs for USB-in transfers are allocated, added to the dev->rxsubmitted anchor and submitted. In the complete callback emsusbreadbulkcallback(), the URBs are processed and resubmitted. In emsusbclose() the URBs are freed by calling usbkillanchoredurbs(&dev->rx_submitted).

However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in emsusbclose().

Fix the memory leak by anchoring the URB in the emsusbreadbulkcallback() to the dev->rx_submitted anchor.(CVE-2026-23058)

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

locking/rtmutex: Skip remove_waiter() when waiter is not enqueued

syzbot triggered the following splat in removewaiter() via FUTEXCMPREQUEUEPI:

KASAN: null-ptr-deref in range [0x0000000000000a88-0x0000000000000a8f] classrawspinlockconstructor removewaiter+0x159/0x1200 kernel/locking/rtmutex.c:1561 rtmutexstartproxylock+0x103/0x120 futex_requeue+0x10e4/0x20d0 __x64sysfutex+0x34f/0x4d0

taskblocksonrtmutex() does not arm the waiter upon deadlock detection, leaving waiter->task nil, where 3bfdc63936dd ("rtmutex: Use waiter::task instead of current in remove_waiter()") made this fatal.

Furthermore, rtmutexstartproxylock() should not be calling into removewaiter() upon a successfully grabbing the rtmutex. 1a1fb985f2e2 ("futex: Handle early deadlock return correctly"), moved the removewaiter() out of __rtmutexstartproxylock() (where 'ret' was only ever 0 or < 0) into the wrapper. Tighten this check to account for trytotakertmutex().(CVE-2026-53163)

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

USB: serial: omninet: fix memory corruption with small endpoint

Make sure that the bulk-out buffers are at least as large as the hardcoded transfer size to avoid user-controlled slab corruption should a malicious device report a smaller endpoint max packet size than expected.(CVE-2026-63928)

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

security/keys: fix missed RCU read section on lookup

Nicholas Carlini reports that the keyring code calls assocarrayfind() in findkeytoupdate() without holding the RCU read lock, while the assocarray_gc() code really is designed around removing the node from the tree and then freeing it after an RCU grace-period.

The regular key handling doesn't see this because holding the keyring semaphore hides any lifetime issues, but the persistent key handling uses a different model.

Instead of extending the keyring locking, just do the simple RCU locking that the assoc_array was designed for.(CVE-2026-64015)

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

xfs: resample the data fork mapping after cycling ILOCK

xfsreflinkfill_{cowhole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfsfindtrimcowextent, but we don't refresh the data fork mapping beforehand, which means that the xfsbmaptrimcow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared.

If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.(CVE-2026-64600)