OESA-2026-2495

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

udp: Fix wildcard bind conflict check when using hash2

When binding a udp_sock to a local address and port, UDP uses two hashes (udptable->hash and udptable->hash2) for collision detection. The current code switches to "hash2" when hslot->count > 10.

"hash2" is keyed by local address and local port. "hash" is keyed by local port only.

The issue can be shown in the following bind sequence (pseudo code):

bind(fd1, "[fd00::1]:8888") bind(fd2, "[fd00::2]:8888") bind(fd3, "[fd00::3]:8888") bind(fd4, "[fd00::4]:8888") bind(fd5, "[fd00::5]:8888") bind(fd6, "[fd00::6]:8888") bind(fd7, "[fd00::7]:8888") bind(fd8, "[fd00::8]:8888") bind(fd9, "[fd00::9]:8888") bind(fd10, "[fd00::10]:8888")

/* Correctly return -EADDRINUSE because "hash" is used * instead of "hash2". udpliblportinuse() detects the * conflict. */ bind(failfd, "[::]:8888")

/* After one more socket is bound to "[fd00::11]:8888", * hslot->count exceeds 10 and "hash2" is used instead. / bind(fd11, "[fd00::11]:8888") bind(fail_fd, "[::]:8888") / succeeds unexpectedly */

The same issue applies to the IPv4 wildcard address "0.0.0.0" and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For example, if there are existing sockets bound to "192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or "[::ffff:0.0.0.0]:8888" can also miss the conflict when hslot->count > 10.

TCP inetcskgetport() already has the correct check in inetusebhash2onbind(). Rename it to inetusehash2onbind() and move it to inethashtables.h so udp.c can reuse it in this fix.(CVE-2026-31503)

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

scsi: target: tcmloop: Drain commands in targetreset handler

tcmlooptargetreset() violates the SCSI EH contract: it returns SUCCESS without draining any in-flight commands. The SCSI EH documentation (scsieh.rst) requires that when a reset handler returns SUCCESS the driver has made lower layers "forget about timed out scmds" and is ready for new commands. Every other SCSI LLD (virtioscsi, mpt3sas, ipr, scsidebug, mpi3mr) enforces this by draining or completing outstanding commands before returning SUCCESS.

Because tcmlooptargetreset() doesn't drain, the SCSI EH reuses in-flight scsicmnd structures for recovery commands (e.g. TUR) while the target core still has async completion work queued for the old secmd. The memset in queuecommand zeroes selun and lunrefactive, causing transportlunremovecmd() to skip its percpurefput(). The leaked LUN reference prevents transportclearlunref() from completing, hanging configfs LUN unlink forever in D-state:

INFO: task rm:264 blocked for more than 122 seconds. rm D 0 264 258 0x00004000 Call Trace: __schedule+0x3d0/0x8e0 schedule+0x36/0xf0 transportclearlunref+0x78/0x90 [targetcoremod] coretpgremovelun+0x28/0xb0 [targetcoremod] targetfabricportunlink+0x50/0x60 [targetcoremod] configfsunlink+0x156/0x1f0 [configfs] vfsunlink+0x109/0x290 dounlinkat+0x1d5/0x2d0

Fix this by making tcmlooptarget_reset() actually drain commands:

1. Issue TMRLUNRESET via tcmloopissuetmr() to drain all commands that the target core knows about (those not yet CMDT_COMPLETE).

2. Use blkmqtagsetbusyiter() to iterate all started requests and flushwork() on each secmd — this drains any deferred completion work for commands that already had CMDTCOMPLETE set before the TMR (which the TMR skips via __targetcheckiostate()). This is the same pattern used by mpi3mr, scsidebug, and libsas to drain outstanding commands during reset.(CVE-2026-43054)

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

net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback

NETIFFIPV6_CSUM only advertises support for checksum offload of packets without IPv6 extension headers. Packets with extension headers must fall back onto software checksumming. Since TSO depends on checksum offload, those must revert to GSO.

The below commit introduces that fallback. It always checks network header length. For tunneled packets, the inner header length must be checked instead. Extend the check accordingly.

A special case is tunneled packets without inner IP protocol. Such as RFC 6951 SCTP in UDP. Those are not standard IPv6 followed by transport header either, so also must revert to the software GSO path.(CVE-2026-43057)

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

Bluetooth: hcisync: annotate data-races around hdev->reqstatus

_hcicmdsyncsk() sets hdev->reqstatus under hdev->reqlock:

hdev->req_status = HCI_REQ_PEND;

However, several other functions read or write hdev->req_status without holding any lock:

• hcisendcmdsync() reads reqstatus in hcicmdwork (workqueue)
• hcicmdsync_complete() reads/writes from HCI event completion
• hcicmdsynccancel() / hcicmdsynccancel_sync() read/write
• hciabortconn() reads in connection abort path

Since _hcicmdsyncsk() runs on hdev->reqworkqueue while hcisendcmdsync() runs on hdev->workqueue, these are different workqueues that can execute concurrently on different CPUs. The plain C accesses constitute a data race.

Add READONCE()/WRITEONCE() annotations on all concurrent accesses to hdev->reqstatus to prevent potential compiler optimizations that could affect correctness (e.g., load fusing in the waitevent condition or store reordering).(CVE-2026-43119)

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

fbcon: check return value of con2fbacquirenewinfo()

If fbconopen() fails when called from con2fbacquirenewinfo() then info->fbconpar pointer remains NULL which is later dereferenced.

Add check for return value of the function con2fbacquirenewinfo() to avoid it.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2026-43123)

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

Bluetooth: L2CAP: Fix missing key size check for L2CAPLECONN_REQ

This adds a check for encryption key size upon receiving L2CAPLECONNREQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAPCRLEBADKEYSIZE.(CVE-2026-43134)

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

usb: dwc3: gadget: Move vbus draw to workqueue context

Currently dwc3gadgetvbus_draw() can be called from atomic context, which in turn invokes power-supply-core APIs. And some these PMIC APIs have operations that may sleep, leading to kernel panic.

Fix this by moving the vbus_draw into a workqueue context.(CVE-2026-43170)

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

media: pvrusb2: fix URB leak in pvr2sendrequest_ex

When pvr2sendrequestex() submits a write URB successfully but fails to submit the read URB (e.g. returns -ENOMEM), it returns immediately without waiting for the write URB to complete. Since the driver reuses the same URB structure, a subsequent call to pvr2sendrequestex() attempts to submit the still-active write URB, triggering a 'URB submitted while active' warning in usbsubmiturb().

Fix this by ensuring the write URB is unlinked and waited upon if the read URB submission fails.(CVE-2026-43223)

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

perf/x86/intel/uncore: Fix die ID init and look up bugs

In snbeppci2phymapinit(), in the nrnodeids > 8 path, uncoredevicetodie() may return -1 when all CPUs associated with the UBOX device are offline.

Remove the WARNONONCE(die_id == -1) check for two reasons:

• The current code breaks out of the loop. This is incorrect because pcigetdevice() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan.

• Returning -EINVAL is incorrect, since marking offline buses with die_id == -1 is expected and should not be treated as an error.

Separately, when NUMA is disabled on a NUMA-capable platform, pcibustonode() returns NUMANONODE, causing uncoredevicetodie() to return -1 for all PCI devices. As a result, sprupdatedevicelocation(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree.

Fix this by using uncorepcibustodieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbeppci2phymapinit() to be added in spruncorepci_init().

Keep uncoredevicetodie() only for the nrnode_ids > 8 case, where NUMA is expected to be enabled.(CVE-2026-43344)

The Linux kernel Nouveau graphics driver has a race condition/null pointer dereference issue in DPCD (DisplayPort Configuration Data) AUX channel transmission processing. When the GPU device enters the suspend state due to runtime power management (runtime PM), if the user space program (such as through the /dev/drmdp interface) attempts to initiate an AUX transfer request, the driver will try to access the GSP (Graphics System Processor) firmware code of the suspended device, causing the kernel to crash.(CVE-2026-43381)

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

ceph: add a bunch of missing cephpathinfo initializers

cephmdscbuildpath() must be called with a zero-initialized cephpathinfo parameter, or else the following cephmdscfreepath_info() may crash.

Example crash (on Linux 6.18.12):

virttocache: Object is not a Slab page! WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6732 kmemcachefree+0x316/0x400 [...] Call Trace: [...] cephopen+0x13d/0x3e0 dodentryopen+0x134/0x480 vfsopen+0x2a/0xe0 pathopenat+0x9a3/0x1160 [...] cachefromobj: Wrong slab cache. namescache but object is from cephinodeinfo WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6746 kmemcachefree+0x2dd/0x400 [...] kernel BUG at mm/slub.c:634! Oops: invalid opcode: 0000 [#1] SMP NOPTI RIP: 0010:_slabfree+0x1a4/0x350

Some of the cephmdscbuildpath() callers had initializers, but others had not, even though they were all added by commit 15f519e9f883 ("ceph: fix race condition validating rparent before applying state"). The ones without initializer are suspectible to random crashes. (I can imagine it could even be possible to exploit this bug to elevate privileges.)

Unfortunately, these Ceph functions are undocumented and its semantics can only be derived from the code. I see that cephmdscbuild_path() initializes the structure only on success, but not on error.

Calling cephmdscfreepathinfo() after a failed cephmdscbuild_path() call does not even make sense, but that's what all callers do, and for it to be safe, the structure must be zero-initialized. The least intrusive approach to fix this is therefore to add initializers everywhere.(CVE-2026-43408)

In the Linux kernel, the following vulnerability has been resolved: powerpc, perf: Check that current->mm is alive before getting user callchain. It may happen that mm is already released, which leads to kernel panic. This adds the NULL check for current->mm, similarly to commit 20afc60f892d ("x86, perf: Check that current->mm is alive before getting user callchain"). I was getting this panic when running a profiling BPF program (profile.py from bcc-tools). In addition, move storing the top-level stack entry to generic perfcallchainuser to make sure the top-level entry is always captured, even if current->mm is NULL.(CVE-2026-43416)

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

unshare: fix unshare_fs() handling

There's an unpleasant corner case in unshare(2), when we have a CLONENEWNS in flags and current->fs hadn't been shared at all; in that case copymnt_ns() gets passed current->fs instead of a private copy, which causes interesting warts in proof of correctness]

> I guess if private means fs->users == 1, the condition could still be true.

Unfortunately, it's worse than just a convoluted proof of correctness. Consider the case when we have CLONENEWCGROUP in addition to CLONENEWNS (and current->fs->users == 1).

We pass current->fs to copymntns(), all right. Suppose it succeeds and flips current->fs->{pwd,root} to corresponding locations in the new namespace. Now we proceed to copycgroupns(), which fails (e.g. with -ENOMEM). We call putmntns() on the namespace created by copymntns(), it's destroyed and its mount tree is dissolved, but... current->fs->root and current->fs->pwd are both left pointing to now detached mounts.

They are pinning those, so it's not a UAF, but it leaves the calling process with unshare(2) failing with -ENOMEM and leaving it with pwd and root on detached isolated mounts. The last part is clearly a bug.

There is other fun related to that mess (races with pivotroot(), including the one between pivotroot() and fork(), of all things), but this one is easy to isolate and fix - treat CLONENEWNS as "allocate a new fsstruct even if it hadn't been shared in the first place". Sure, we could go for something like "if both CLONENEWNS and one of the things that might end up failing after copymntns() call in createnewnamespaces() are set, force allocation of new fsstruct", but let's keep it simple - the cost of copyfsstruct() is trivial.

Another benefit is that copymntns() with CLONENEWNS always gets a freshly allocated fsstruct, yet to be attached to anything. That seriously simplifies the analysis...

FWIW, that bug had been there since the introduction of unshare(2) ;-/(CVE-2026-43472)

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

KVM: SVM: Set/clear CR8 write interception when AVIC is (de)activated

Explicitly set/clear CR8 write interception when AVIC is (de)activated to fix a bug where KVM leaves the interception enabled after AVIC is activated. E.g. if KVM emulates INIT=>WFS while AVIC is deactivated, CR8 will remain intercepted in perpetuity.

On its own, the dangling CR8 intercept is "just" a performance issue, but combined with the TPR sync bug fixed by commit d02e48830e3f ("KVM: SVM: Sync TPR from LAPIC into VMCB::V_TPR even if AVIC is active"), the danging intercept is fatal to Windows guests as the TPR seen by hardware gets wildly out of sync with reality.

Note, VMX isn't affected by the bug as TPRTHRESHOLD is explicitly ignored when Virtual Interrupt Delivery is enabled, i.e. when APICv is active in KVM's world. I.e. there's no need to trigger updatecr8_intercept(), this is firmly an SVM implementation flaw/detail.

WARN if KVM gets a CR8 write #VMEXIT while AVIC is active, as KVM should never enter the guest with AVIC enabled and CR8 writes intercepted.

Squash fix to avicdeactivatevmcb. - Paolo

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

lib/crypto: mpi: Fix integer underflow in mpireadrawfromsgl()

Yiming reports an integer underflow in mpireadrawfromsgl() when subtracting "lzeros" from the unsigned "nbytes".

For this to happen, the scatterlist "sgl" needs to occupy more bytes than the "nbytes" parameter and the first "nbytes + 1" bytes of the scatterlist must be zero. Under these conditions, the while loop iterating over the scatterlist will count more zeroes than "nbytes", subtract the number of zeroes from "nbytes" and cause the underflow.

When commit 2d4d1eea540b ("lib/mpi: Add mpi sgl helpers") originally introduced the bug, it couldn't be triggered because all callers of mpireadrawfromsgl() passed a scatterlist whose length was equal to "nbytes".

However since commit 63ba4d67594a ("KEYS: asymmetric: Use new crypto interface without scatterlists"), the underflow can now actually be triggered. When invoking a KEYCTLPKEYENCRYPT system call with a larger "outlen" than "inlen" and filling the "in" buffer with zeroes, cryptoakciphersyncprep() will create an all-zero scatterlist used for both the "src" and "dst" member of struct akcipherrequest and thereby fulfil the conditions to trigger the bug:

syskeyctl() keyctlpkeyeds() asymmetrickeyedsop() softwarekeyedsop() cryptoakciphersyncencrypt() cryptoakciphersyncprep() cryptoakcipherencrypt() rsaenc() mpireadrawfromsgl()

To the user this will be visible as a DoS as the kernel spins forever, causing soft lockup splats as a side effect.

Fix it.(CVE-2026-43492)