OESA-2026-2993

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ALSA: usb-audio: Fix use-after-free in sndusbmixer_free()

When sndusbcreatemixer() fails, sndusbmixerfree() frees mixer->idelems but the controls already added to the card still reference the freed memory. Later when sndcard_register() runs, the OSS mixer layer calls their callbacks and hits a use-after-free read.

Call trace: getctlvalue+0x63f/0x820 sound/usb/mixer.c:411 getminmaxwithquirks.isra.0+0x240/0x1f40 sound/usb/mixer.c:1241 mixerctlfeatureinfo+0x26b/0x490 sound/usb/mixer.c:1381 sndmixerossbuildtest+0x174/0x3a0 sound/core/oss/mixeross.c:887 ... sndcardregister+0x4ed/0x6d0 sound/core/init.c:923 usbaudioprobe+0x5ef/0x2a90 sound/usb/card.c:1025

Fix by calling sndctlremove() for all mixer controls before freeing idelems. We save the next pointer first because sndctl_remove() frees the current element.(CVE-2026-23089)

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

Bluetooth: serialize accept_q access

btsockpoll() walks the accept queue without synchronization, while child teardown can unlink the same socket and drop its last reference. The unsynchronized accept queue walk has existed since the initial Bluetooth import.

Protect acceptq with a dedicated lock for queue updates and polling. Also rework btaccept_dequeue() to take temporary child references under the queue lock before dropping it and locking the child socket.(CVE-2026-52918)

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

pppoe: drop PFC frames

RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT RECOMMENDED for PPPoE. In practice, pppd does not support negotiating PFC for PPPoE sessions, and the current PPPoE driver assumes an uncompressed (2-byte) protocol field. However, the generic PPP layer function ppp_input() is not aware of the negotiation result, and still accepts PFC frames.

If a peer with a broken implementation or an attacker sends a frame with a compressed (1-byte) protocol field, the subsequent PPP payload is shifted by one byte. This causes the network header to be 4-byte misaligned, which may trigger unaligned access exceptions on some architectures.

To reduce the attack surface, drop PPPoE PFC frames. Introduce pppskbiscompressedproto() helper function to be used in both ppp_generic.c and pppoe.c to avoid open-coding.(CVE-2026-53003)

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

crypto: ccp - copy IV using skcipher ivsize

AF_ALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.

ccpaescomplete() restores AESBLOCKSIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer.

Use cryptoskcipherivsize() to copy only the algorithm's IV length.(CVE-2026-53016)

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

ppp: require CAPNETADMIN in target netns for unattached ioctls

/dev/ppp open is currently authorized against file->fcred->userns, while unattached administrative ioctls operate on current->nsproxy->net_ns.

As a result, a local unprivileged user can create a new user namespace with CLONENEWUSER, gain CAPNET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace.

Require CAPNETADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls.

This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case.(CVE-2026-53075)

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

bpf: Fix ld_{abs,ind} failure path analysis in subprogs

Usage of ld_{abs,ind} instructions got extended into subprogs some time ago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). These are only allowed in subprograms when the latter are BTF annotated and have scalar return types.

The code generator in bpfgenldabs() has an abnormal exit path (r0=0 + exit) from legacy cBPF times. While the enforcement is on scalar return types, the verifier must also simulate the path of abnormal exit if the packet data load via ld{abs,ind} failed.

This is currently not the case. Fix it by having the verifier simulate both success and failure paths, and extend it in similar ways as we do for tail calls. The success path (r0=unknown, continue to next insn) is pushed onto stack for later validation and the r0=0 and return to the caller is done on the fall-through side.(CVE-2026-53090)

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

vdpa: 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:

drm/amd/display: Clamp HDMI HDCP2 rxidlist read to buffer size

[Why & How] During HDCP 2.x repeater authentication over HDMI, the driver reads the sink's RxStatus register and extracts a 10-bit message size field (max value 1023). This value is used as the read length for the ReceiverID list without being clamped to the size of the destination buffer rxidlist[177]. A malicious HDMI repeater could advertise a message size larger than the buffer, causing an out-of-bounds write during the I2C read.

Clamp the read length in modhdcpreadrxidlist() to the size of the rxid_list buffer, matching the approach already used in the DP branch.

(cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)(CVE-2026-53137)

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

RDMA/srp: bound SRP_RSP sense copy by the received length

srpprocessrsp() copies sense data from rsp->data + respdatalen, where respdatalen is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->bytelen). The copy length is bounded to SCSISENSE_BUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded.

A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRPRSP with SRPRSPFLAGSNSVALID set and a large respdatalen. The receive buffer is allocated at the target-chosen maxtiiulen, so the source of the sense copy lands past the bytes actually received; with respdata_len near 0xFFFFFFFF it is gigabytes past the buffer and the read faults.

Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->bytelen; this brings ibsrp into line with them.(CVE-2026-53186)

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

drm/amd/display: Fix out-of-bounds read in dpgeteqauxrd_interval()

[Why & How] The auxrdinterval array in struct dclttprcaps is declared with MAXREPEATERCNT - 1 (7) elements, indexed 0..6. However, the offset parameter passed to dpgeteqauxrdinterval() can be as large as MAXREPEATERCNT (8) when a sink reports 8 LTTPR repeaters via DPCD. This leads to an out-of-bounds read of auxrd_interval[7] when offset is 8.

Fix this by growing auxrdinterval to MAXREPEATERCNT elements to accommodate the full range of valid repeater counts defined by the DP spec.

(cherry picked from commit a55a458a8df37a65ffda5cf721d554a8f74f6b04)(CVE-2026-53330)