OESA-2026-3316

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

NFSv4/flexfiles: reject zero filehandle version count

fflayoutalloclseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzallocobjs(), and the current code only rejects NULL.

A zero count yields ZEROSIZEPTR, which can be stored in dssinfo->fhversions even though later flexfiles paths assume that at least one filehandle version exists.

Reject fhcount == 0 before the allocation, matching the existing zero versioncount validation in the flexfiles GETDEVICEINFO parser.

A QEMU/KASAN run with a malformed flexfiles layout hit:

KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:fflayoutencodefflayoutupdate.isra.0+0x15f/0x750 fflayoutencodelayoutreturn+0x683/0x970 nfs4xdrenclayoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception

The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly.(CVE-2026-53392)

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

nfsd: release layout stid on setlease failure

nfs4allocstid() publishes the new stid into cl->clstateids via idralloccyclic() under cllock before returning to nfsd4alloclayoutstateid(). When nfsd4layoutsetlease() then fails, the error path frees the layout stateid directly with kmemcachefree() without ever calling idrremove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (states_show, client teardown) dereferences the dangling pointer.

The correct teardown for an IDR-published stid is nfs4putstid(), which removes the IDR slot under cllock, dispatches scfree (nfsd4freelayoutstateid) to release ls->lsfile via nfsd4closelayout(), and drops the nfs4_file reference in its tail.

A second issue blocks that switch: nfsd4freelayoutstateid() unconditionally inspects ls->lsfencework via delayedworkpending() under lslock, but INITDELAYEDWORK(&ls->lsfencework, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayed_work.

nfsd4_alloc_layout_stateid()
  nfs4_alloc_stid()           /* idr_alloc_cyclic under cl_lock */
  nfsd4_layout_setlease()     /* fails */
    nfs4_put_stid()
      nfsd4_free_layout_stateid()
        delayed_work_pending(&ls->ls_fence_work)  /* needs INIT */
        nfsd4_close_layout()  /* nfsd_file_put(ls->ls_file) */
      put_nfs4_file()

Fix by hoisting the lsfenced / lsfencedelay / INITDELAYEDWORK initialization above the nfsd4layoutsetlease() call, and replace the manual nfsdfileput + putnfs4file + kmemcachefree cleanup with a single nfs4put_stid(stp).(CVE-2026-53399)

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

i2c: stub: Reject I2C block transfers with invalid length

The I2CSMBUSI2CBLOCKDATA case in stubxfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2CSMBUSBLOCKMAX (32), which is the limit of the union i2csmbusdata.block buffer (34 bytes total). The driver is a development/test tool (CONFIGI2CSTUB=m, not built by default) that must be loaded with a chip_addr= parameter.

A local user with access to /dev/i2c-* can issue an I2CSMBUS ioctl with I2CSMBUSI2CBLOCKDATA and data->block[0] > 32, causing stubxfer() to read or write past the end of the union i2csmbusdata.block buffer:

BUG: KASAN: stack-out-of-bounds in stubxfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: <TASK> stubxfer (drivers/i2c/i2c-stub.c:223) __i2csmbusxfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbusxfer (drivers/i2c/i2c-core-smbus.c:536) i2cdevioctlsmbus (drivers/i2c/i2c-dev.c:391) i2cdevioctl (drivers/i2c/i2c-dev.c:478) __x64sysioctl (fs/ioctl.c:583) dosyscall64 (arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) </TASK>

The bug exists because i2c-stub implements .smbusxfer directly, bypassing the I2CSMBUSBLOCKMAX validation in i2csmbusxferemulated(). The I2CSMBUSBLOCKDATA case in the same function correctly validates against I2CSMBUSBLOCKMAX, but the I2CSMBUSI2CBLOCK_DATA case does not.

Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2CSMBUSBLOCKMAX with -EINVAL, consistent with both the I2CSMBUSBLOCKDATA case in the same function and the I2CSMBUSI2CBLOCKDATA validation in i2csmbusxfer_emulated().(CVE-2026-64191)

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

fuse: re-lock request before returning from fusereffolio()

fusereffolio() unlocks the request but does not re-lock it before returning. fusechanabort() can end the request and the async end callback (eg fusewritepagefree()) can free the args while the subsequent copy chain logic after fusereffolio() accesses them, leading to use-after-free issues.

Fix this by locking the request in fusereffolio() before returning.(CVE-2026-64266)

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

tracing: Prevent out-of-bounds read in glob matching

String event fields are not necessarily NUL-terminated, so the filter predicate functions (filterpredstring(), filterpredstrloc() and filterpredstrrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it.

regexmatchglob() was the exception: it ignored the length and called globmatch(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in globmatch(), reached via regexmatchglob() and filtermatchpreds() from the xfslookup tracepoint.

Add a length-bounded globmatchlen() and use it from regexmatchglob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.(CVE-2026-64299)

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

sched/rt: Have RTPUSHIPI be default off for non PREEMPT_RT

RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead.

Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task.

This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow.

The solution to that was to create an RTPUSHIPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again.

The RTPUSHIPI solved the latency problem with PREEMPTRT but could cause a new issue with non PREEMPTRT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT.

If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it.

A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed.

When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU.

As RTPUSHIPI was created to help PREEMPTRT, make it default off if PREEMPTRT is not enabled.(CVE-2026-64374)

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

smb/client: fix chown/chgrp with SMB3 POSIX Extensions

Ownership (chown) and group (chgrp) modifications were being ignored when mounting with SMB3 POSIX Extensions unless CIFSMOUNTCIFSACL or CIFSMOUNTMODEFROM_SID were also explicitly set.

Fix this by checking for posixextensions in cifssetattrnounix() when updating UID and GID, ensuring that idmodetocifs_acl() is called to map and set the ownership/group information on the server.(CVE-2026-64388)

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

hwrng: virtio: clamp device-reported used.len at copy_data()

randomrecvdone() stores the device-reported used.len directly into vi->dataavail. copydata() then indexes vi->data[] using vi->dataidx (advanced by previous copydata() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMPCACHEBYTES bytes, typically 32 or 64).

A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng.

Concrete impact is inside the guest:

• Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB.

• Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host.

KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000:

BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asanmemcpy+0x23/0x60 virtioread+0x394/0x5d0 hwrngfillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probecommon+0xa5/0x660 virtiodevprobe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)

Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened usb9pfsrxcomplete() against unchecked device-reported length in the USB 9p transport.

With the clamp at point of use and arrayindexnospec() in place, the same harness boots cleanly: copydata() returns zero for the bogus report, the device-supplied bytes after dataidx are discarded, and the driver issues a fresh request.(CVE-2026-64456)