OESA-2026-3454

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

xfs: remove xfsattrleaf_hasname

The calling convention of xfsattrleafhasname() is problematic, because it returns a NULL buffer when xfsattr3leafread fails, a valid buffer when xfsattr3leaflookupint returns -ENOATTR or -EEXIST, and a non-NULL buffer pointer for an already released buffer when xfsattr3leaflookupint fails with other error values.

Fix this by simply open coding xfsattrleafhasname in the callers, so that the buffer release code is done by each caller of xfsattr3leafread.(CVE-2026-43153)

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

x86/kexec: Disable KCOV instrumentation after load_segments()

The loadsegments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIGKCOV is enabled, any subsequent instrumented C code call (e.g. nativegdtinvalidate()) begins crashing the kernel in an endless loop.

To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel:

$ kexec -l /boot/otherKernel $ kexec -e

The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIGKEXEC and CONFIGKCOV to be enabled simultaneously.

Adding safeguards directly to the KCOV fast-path (_sanitizercovtracepc()) is also undesirable as it would introduce an extra performance overhead.

Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machinekexec64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered.

The problem is not relevant for 32 bit kernels as CONFIG_KCOV is not supported there.

bp: Space out comment for better readability.

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

apparmor: Fix & Optimize table creation from possibly unaligned memory

Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses.

• Added Fixes tag
• Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access jj: remove duplicate word "convert" in comment trigger checkpatch warning

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

nvmet-tcp: fix race between ICReq handling and queue teardown

nvmettcphandle_icreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown.

If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before iowork drains the already buffered ICReq. In that case, nvmettcpschedulereleasequeue() sets queue->state to NVMETTCPQDISCONNECTING and drops the queue reference under state_lock.

If iowork later processes that ICReq, nvmettcphandleicreq() can still overwrite the state back to NVMETTCPQLIVE. That defeats the DISCONNECTING-state guard in nvmettcpschedulereleasequeue() and allows a later socket state change to re-enter teardown and issue a second krefput() on an already released queue.

The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMETTCPQ_FAILED, again reopening the window for a second teardown path to drop the queue reference.

Fix this by serializing both post-send state transitions with state_lock and bailing out if teardown has already started.

Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmettcpsocketerror() setting rcvstate to NVMETTCPRECV_ERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.(CVE-2026-46135)

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

netfilter: nftables: use listdel_rcu for netlink hooks

nftnetdevunregister_hooks and __nftunregisterflowtablenethooks need to use listdelrcu(), this list can be walked by concurrent dumpers.

Add a new helper and use it consistently.(CVE-2026-46324)

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

RDMA: During reregmr ensure that REREGACCESS is compatible

If IBMRREREGACCESS changes from RO to RW then the umem has to be re-evaluated to ensure it is properly pinned as RW. Since the umem is hidden inside each driver's mr struct add a ibumemcheckrereg() function that each driver has to call before processing IBMRREREG_ACCESS.

mlx4 has to retain its duplicate ibaccesswritable check because it implements IBMRREREGACCESS | IBMRREREGTRANS by changing both items in place sequentially while the MR is live, so it will continue to not support this combination.(CVE-2026-52908)

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:

ipc: limit next_id allocation to the valid ID range

The checkpoint/restore sysctl path can request the next SysV IPC id through ids->nextid. ipcidralloc() currently forwards that request to idralloc() with an open-ended upper bound.

If the valid tail of the SysV IPC id space is full, the allocation can spill beyond ipc_mni. The returned SysV IPC id still uses the normal index encoding, so later lookup and removal can target the wrong slot. This leaves the real IDR entry behind and breaks the IDR state for the object.

The bug is in ipcidralloc() in the checkpoint/restore path.

1. ids->next_id is passed to:

   idralloc(&ids->ipcsidr, new, ipcidtoidx(next_id), 0, ...)

2. The zero upper bound makes the allocation effectively open-ended. Once the valid SysV IPC tail is occupied, idralloc() can spill past ipcmni and allocate an entry beyond the valid IPC id range.

3. The new object id is still encoded with the narrower SysV IPC index width:

   new->id = (new->seq << ipcmni_seq_shift()) + idx
   

4. Later removal goes through ipc_rmid(), which uses:

   ipcid_to_idx(ipcp->id)
   

   That truncates the real IDR index. An object actually stored at a high index can then be removed as if it lived at a low in-range index.

5. For shared memory, shm_destroy() frees the current object anyway, but the real high IDR slot is left behind as a dangling pointer.

6. A subsequent walk of /proc/sysvipc/shm reaches the stale IDR entry and dereferences freed memory.

Prevent this by bounding the requested allocation to ipc_mni so the checkpoint/restore path fails once the valid range is exhausted.(CVE-2026-52923)

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

ipc/shm: serialize orphan cleanup with shm_nattch updates

shmdestroyorphaned() walks the shm idr under shmids(ns).rwsem, but that does not serialize all fields tested by shmmaydestroy(). In particular, shmnattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem.

Do not decide that an orphaned segment is unused before taking the object lock. Move the shmmaydestroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.(CVE-2026-52930)

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

i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl

While fuzzing with Syzkaller, a persistent schedule_timeout: wrong timeout value warning was observed, accompanied by SMBus controller state machine corruption.

The I2CTIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INTMAX, but it is subsequently multiplied by 10 before being passed to msecstojiffies().

A malicious user can pass a large value (e.g., 429496729) that passes the arg > INT_MAX check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal (int)m < 0 check in msecs_to_jiffies().

The truncated value is then assigned to client->adapter->timeout (a signed 32-bit int), which is reinterpreted as a negative number. When passed to waitforcompletion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the schedule_timeout warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS).

Fix this by bounding the user argument to INT_MAX / 10.

wsa: move the comment as well

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

iommu/vt-d: Fix oops due to out of scope access

Below oops triggers when kill QEMU process:

Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI Call Trace: <TASK> dorawspinlock+0xaa/0xc0 rawspinlockirqsave+0x21/0x40 domainremovedevpasid+0x52/0x160 intelnestedsetdevpasid+0x1b9/0x1e0 __iommusetgrouppasid+0x56/0x120 pcidevresetiommudone+0xe3/0x180 pcieflr+0x65/0x160 __pciresetfunctionlocked+0x5b/0x120 vfiopcicoreclosedevice+0x63/0xe0 [vfiopcicore] vfiodfclose+0x4f/0xa0 vfiodfunbindiommufd+0x2d/0x60 vfiodevicefops_release+0x3e/0x40 __fput+0xe5/0x2c0 taskworkrun+0x58/0xa0 doexit+0x2c8/0x600 dogroupexit+0x2f/0xa0 getsignal+0x863/0x8c0 archdosignalorrestart+0x24/0x100 exittousermodeloop+0x87/0x380 dosyscall64+0x2ff/0x11e0 entrySYSCALL64afterhwframe+0x76/0x7e

The global static blocked domain is a dummy domain without corresponding dmardomain structure, accessing beyond iommudomain structure triggers oops easily. Fix it by return early in domainremovedev_pasid() like identity domain.(CVE-2026-52953)

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

ceph: fix BUG_ON in _cephbuildxattrsblob() due to stale blob size

The generic/642 test-case can reproduce the kernel crash:

[40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr cephconworkfn [40243.612715] RIP: 0010:__cephbuildxattrs_blob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000 [40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0 [40243.627408] Call Trace: [40243.627839] <TASK> [40243.628188] __prepcap+0x3fd/0x4a0 [40243.628789] ? dorawspinunlock+0x4e/0xe0 [40243.629474] cephcheckcaps+0x46a/0xc80 [40243.630094] ? __lockacquire+0x4a2/0x2650 [40243.630773] ? findheldlock+0x31/0x90 [40243.631347] ? handlecapgrant+0x79f/0x1060 [40243.632068] ? lockrelease+0xd9/0x300 [40243.632696] ? __mutexunlockslowpath+0x3e/0x340 [40243.633429] ? lockrelease+0xd9/0x300 [40243.634052] handlecapgrant+0xcf6/0x1060 [40243.634745] cephhandlecaps+0x122b/0x2110 [40243.635415] mdsdispatch+0x5bd/0x2160 [40243.636034] ? cephconprocessmessage+0x65/0x190 [40243.636828] ? lockrelease+0xd9/0x300 [40243.637431] cephconprocessmessage+0x7a/0x190 [40243.638184] ? kfree+0x311/0x4f0 [40243.638749] ? kfree+0x311/0x4f0 [40243.639268] processmessage+0x16/0x1a0 [40243.639915] ? sgfreetable+0x39/0x90 [40243.640572] cephconv2tryread+0xf58/0x2120 [40243.641255] ? lockacquire+0xc8/0x300 [40243.641863] cephconworkfn+0x151/0x820 [40243.642493] processonework+0x22f/0x630 [40243.643093] ? processonework+0x254/0x630 [40243.643770] workerthread+0x1e2/0x400 [40243.644332] ? __pfxworkerthread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ? __pfxkthread+0x10/0x10 [40243.646125] retfrom_fork+0x3f8/0x480 [40243.646752] ? __pfx_kthread+0x10/0x10 [40243.647316] ? __pfxkthread+0x10/0x10 [40243.647919] retfromforkasm+0x1a/0x30 [40243.648556] </TASK> [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intelraplmsr intelraplcommon inteluncorefrequencycommon skxedaccommon nfit kvmintel kvm irqbypass joydev ghashclmulniintel aesniintel rapl inputleds machid psmouse vga16fb serioraw vgastate floppy i2cpiix4 pataacpi bochs qemufwcfg i2csmbus schfqcodel rbd dmcrypt msr parportpc ppdev lp parport efipstore [40243.654766] ---[ end trace 0000000000000000 ]---

Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") moved the requiredblobsize computation to before the _buildxattrs() call, introducing a race.

__buildxattrs() releases and reacquires iceph_lock during execution. In that window, handlecapgrant() may update ixattrs.blob with a newer MDS-provided blob and bump ixattrs.version. When __bui ---truncated---(CVE-2026-52961)

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

fsnotify: fix inode reference leak in fsnotifyrecalcmask()

fsnotifyrecalcmask() fails to handle the return value of _fsnotifyrecalcmask(), which may return an inode pointer that needs to be released via fsnotifydropobject() when the connector's HASIREF flag transitions from set to cleared.

This manifests as a hung task with the following call trace:

INFO: task umount:1234 blocked for more than 120 seconds. Call Trace: __schedule schedule fsnotifysbdelete genericshutdownsuper killanonsuper cleanupmnt taskworkrun doexit dogroupexit

The race window that triggers the iref leak:

Thread A (adding mark) Thread B (removing mark) ────────────────────── ──────────────────────── fsnotifyaddmarklocked(): fsnotifyaddmarklist(): spinlock(conn->lock) add markB(evictable) to list spin_unlock(conn->lock) return

/* ---- gap: no lock held ---- */

                                  fsnotify_detach_mark(mark_A):
                                    spin_lock(mark_A->lock)
                                    clear ATTACHED flag on mark_A
                                    spin_unlock(mark_A->lock)
                                    fsnotify_put_mark(mark_A)

fsnotify_recalc_mask():
  spin_lock(conn->lock)
  __fsnotify_recalc_mask():
    /* mark_A skipped: ATTACHED cleared */
    /* only mark_B(evictable) remains */
    want_iref = false
    has_iref = true  /* not yet cleared */
    -> HAS_IREF transitions true -> false
    -> returns inode pointer
  spin_unlock(conn->lock)
  /* BUG: return value discarded!
   * iput() and fsnotify_put_sb_watched_objects()
   * are never called */

Fix this by deferring the transition true -> false of HASIREF flag from fsnotifyrecalcmask() (Thread A) to fsnotifyput_mark() (thread B).(CVE-2026-52990)

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

erofs: unify lcn as u64 for 32-bit platforms

As sashiko reported [1], lcn was typed as unsigned long (or unsigned int sometimes), which is only 32 bits wide on 32-bit platforms, which causes (lcn << lclusterbits) to be truncated at 4 GiB.

In order to consolidate the logic, just use u64 consistently around the codebase.

[1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com(CVE-2026-53015)

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

iommu/amd: Fix clone_alias() to use the original device's devid

Currently clonealias() assumes first argument (pdev) is always the original device pointer. This function is called by pciforeachdma_alias() which based on topology decides to send original or alias device details in first argument.

This meant that the source devid used to look up and copy the DTE may be incorrect, leading to wrong or stale DTE entries being propagated to alias device.

Fix this by passing the original pdev as the opaque data argument to both the direct clonealias() call and pciforeachdmaalias(). Inside clonealias(), retrieve the original device from data and compute devid from it.(CVE-2026-53053)

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

USB: serial: kl5kusb105: fix bulk-out buffer overflow

klsi105preparewritebuffer() is called by the generic write path with the bulk-out buffer and its size (bulkoutsize, 64 bytes). It stores a two-byte length header at the start of the buffer and copies the payload from the write fifo starting at buf + KLSIHDRLEN, but passes the full buffer size as the number of bytes to copy:

count = kfifooutlocked(&port->writefifo, buf + KLSIHDR_LEN, size, &port->lock);

When the fifo holds at least size bytes, size bytes are copied starting two bytes into the size-byte buffer, writing KLSIHDRLEN bytes past its end. Copy at most size - KLSIHDRLEN bytes instead, leaving room for the header as safe_serial already does.

Writing bulkoutsize or more bytes to the tty triggers a slab out-of-bounds write, observed with KASAN by emulating the device with dummy_hcd and raw-gadget:

BUG: KASAN: slab-out-of-bounds in kfifocopyout+0x83/0xc0 Write of size 64 at addr ffff888112c62202 by task python3 kfifocopyout klsi105preparewritebuffer [kl5kusb105] usbserialgenericwritestart [usbserial] Allocated by task 139: usbserialprobe [usbserial] The buggy address is located 2 bytes inside of allocated 64-byte region

The out-of-bounds write no longer occurs with this change applied.(CVE-2026-53194)

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

USB: serial: ioti: fix heap overflow in getmanuf_info()

getmanufinfo() reads le16tocpu(romdesc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmallocobj(), which is sizeof(struct edgetimanuf_descriptor) = 10 bytes.

The Size field comes from the device and is only validated (in checki2cimage()) to make sure the descriptor fits within TIMAXI2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver.

validcsum() is called after readrom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access.

Fix by rejecting descriptors with unexpected length before calling read_rom().

johan: amend commit message; also check for short descriptors

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

l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()

pppol2tpioctl() read sock->sk->skuserdata directly without any locks or reference counting. If a controllable sleep was induced during copyfromuser() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tpsessionclose() asynchronously. This frees the l2tpsession structure via the l2tpsessiondel_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF).

Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tpsocktosession(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tpsession_put() is cleanly called on all return paths to drop the reference.

To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sockdoioctl()).(CVE-2026-53262)

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

drm/amd/display: Wrap DCN32 phantom-plane allocation in DCRUNWITHPREEMPTIONENABLED

[Why] dcn32validatebandwidth() wraps dcn32internalvalidatebw() with DCFPSTART()/DCFPEND(). In x86 non-RT, DCFPSTART takes fpregslock(), which disables local softirqs.

The DML1 path through dcn32enablephantomplane() calls kvzalloc() to allocate ~335 KiB for dcplanestate. This triggers the vmalloc path, which calls BUGON(in_interrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash.

[How] Wrap the dcstatecreatephantomplane() call with the DCRUNWITHPREEMPTIONENABLED() macro to allow preemption during this memory allocation.

(cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)(CVE-2026-53285)

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

drm/amd/display: Avoid NULL dereference in dcdmubsrv error paths

In dcdmubsrvlogdiagnosticdata() and dcdmubsrvenabledpiatrace().

Both functions check:

if (!dcdmubsrv || !dcdmubsrv->dmub)

and then call DCLOGERROR() inside that block.

DCLOGERROR() uses dcdmubsrv->ctx internally. So if dcdmubsrv is NULL, the logging itself can dereference a NULL pointer and cause a crash.

Fix this by splitting the checks.

First check if dcdmubsrv is NULL and return immediately. Then check dcdmubsrv->dmub and log the error only when dcdmubsrv is valid.

Fixes the below: ../display/dc/dcdmubsrv.c:962 dcdmubsrvlogdiagnosticdata() error: we previously assumed 'dcdmubsrv' could be null (see line 961) ../display/dc/dcdmubsrv.c:1167 dcdmubsrvenabledpiatrace() error: we previously assumed 'dcdmubsrv' could be null (see line 1166)(CVE-2026-53313)

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

padata: Put CPU offline callback in ONLINE section to allow failure

syzbot reported the following warning:

DEAD callback error for CPU1
WARNING: kernel/cpu.c:1463 at _cpu_down+0x759/0x1020 kernel/cpu.c:1463, CPU#0: syz.0.1960/14614

at commit 4ae12d8bd9a8 ("Merge tag 'kbuild-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux") which tglx traced to padatacpudead() given it's the only sub-CPUHPTEARDOWNCPU callback that returns an error.

Failure isn't allowed in hotplug states before CPUHPTEARDOWNCPU so move the CPU offline callback to the ONLINE section where failure is possible.(CVE-2026-53314)

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

drm/virtio: Fix driver removal with disabled KMS

DRM atomic and modesetting aren't initialized if virtio-gpu driver built with disabled KMS, leading to access of uninitialized data on driver removal/unbinding and crashing kernel. Fix it by skipping shutting down atomic core with unavailable KMS.(CVE-2026-53347)