OESA-2025-2884

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

usb: xhci: Apply the link chain quirk on NEC isoc endpoints

Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:

[ 1.041954] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhcihcd: AMD-Vi: Event logged [IOPAGEFAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhcihcd: AMD-Vi: Event logged [IOPAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]

It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.

[ 7.041671] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhcihcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhcihcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 31 [ 7.042144] xhcihcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhcihcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 31 [ 7.042266] xhcihcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820

At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.

[ 7.098130] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 13 [ 7.098132] xhcihcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhcihcd: ERROR Transfer event TRB DMA ptr not part of current TD epindex 2 compcode 13 [ 7.098256] xhcihcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2

It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.

Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.

[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhcihcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVEROK cmdage=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 physseg 5 prio class 0

Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.

The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.

No ne ---truncated---(CVE-2025-22022)

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

ksmbd: fix overflow in dacloffset bounds check

The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smbcheckpermdacl() and smbinherit_dacl().

This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.

This patch converts dacloffset to unsigned int and uses checkaddoverflow() to validate access to the DACL.(CVE-2025-22039)

In the Linux kernel, the following vulnerability has been resolved:backlight: ledbl: Hold ledaccess lock when calling ledsysfsdisable()Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 ledsysfsenable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] ledsysfsenable+0x54/0x80 (P) [ 142.507370] ledblremove+0x80/0xa8 [ledbl] [ 142.511742] platformremove+0x30/0x58 [ 142.515501] deviceremove+0x54/0x90 ...Indeed, ledsysfsenable() has to be called with the ledaccesslock held.Hold the lock when calling ledsysfsdisable().(CVE-2025-23144)

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

mfd: ene-kb3930: Fix a potential NULL pointer dereference

The offgpios could be NULL. Add missing check in the kb3930probe(). This is similar to the issue fixed in commit b1ba8bcb2d1f ("backlight: hx8357: Fix potential NULL pointer dereference").

This was detected by our static analysis tool.(CVE-2025-23146)

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

media: venus: hfi: add check to handle incorrect queue size

qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, emptyspace will be bigger than the space actually available. Since newwridx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->qsize

if (wridx >= rdidx) emptyspace = qsize - (wridx - rdidx) .... if (newwridx < qsize) { memcpy(wrptr, packet, dwords << 2) --> OOB write

Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)

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

media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization

On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.(CVE-2025-23160)

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

net: tls: explicitly disallow disconnect

syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be acked. Disconnect is not commonly used, disallow it.

The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger:

WARNING: CPU: 0 PID: 5834 at net/tls/tlsstrp.c:486 tlsstrpmsgload+0x72e/0xa80 net/tls/tlsstrp.c:486 RIP: 0010:tlsstrpmsgload+0x72e/0xa80 net/tls/tlsstrp.c:486 Call Trace: <TASK> tlsrxrecwait+0x280/0xa60 net/tls/tlssw.c:1363 tlsswrecvmsg+0x85c/0x1c30 net/tls/tlssw.c:2043 inet6recvmsg+0x2c9/0x730 net/ipv6/afinet6.c:678 sockrecvmsgnosec net/socket.c:1023 [inline] sockrecvmsg+0x109/0x280 net/socket.c:1045 _sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)

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

ksmbd: fix the warning from _kernelwrite_iter

[ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/readwrite.c:599 _kernelwriteiter+0x21b/0x280

This patch doesn't allow writing to directory.(CVE-2025-37775)

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

ksmbd: fix use-after-free in smbbreakalllevIIoplock()

There is a room in smbbreakalllevIIoplock that can cause racy issues when unlocking in the middle of the loop. This patch use read lock to protect whole loop.(CVE-2025-37776)

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

riscv: uprobes: Add missing fence.i after building the XOL buffer

The XOL (execute out-of-line) buffer is used to single-step the replaced instruction(s) for uprobes. The RISC-V port was missing a proper fence.i (i$ flushing) after constructing the XOL buffer, which can result in incorrect execution of stale/broken instructions.

This was found running the BPF selftests "testprogs: uprobeautoattach, attach_probe" on the Spacemit K1/X60, where the uprobes tests randomly blew up.(CVE-2025-37822)

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

pwm: mediatek: Prevent divide-by-zero in pwmmediatekconfig()

With CONFIGCOMPILETEST && !CONFIGHAVECLK, pwmmediatekconfig() has a divide-by-zero in the following line:

do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));

due to the fact that the !CONFIGHAVECLK version of clkgetrate() returns zero.

This is presumably just a theoretical problem: COMPILETEST overrides the dependency on RALINK which would select COMMONCLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero.

Fixes the following warning:

drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section

ukleinek: s/CONFIGCLK/CONFIGHAVE_CLK/

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

iommu/amd: Fix potential buffer overflow in parseivrsacpihid

There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIIDLEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIIDLEN + 1 but uid string will overflow uid buffer which size is 256.

The same applies to the hid string with length 13 and uid string with length 250.

Check the length of hid and uid strings separately to prevent buffer overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)

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

net/mlx5: Fix ECVF vports unload on shutdown flow

Fix shutdown flow UAF when a virtual function is created on the embedded chip (ECVF) of a BlueField device. In such case the vport acl ingress table is not properly destroyed.

ECVF functionality is independent of ecpfvportexists capability and thus functions mlx5eswitch(enable|disable)pfvf_vports() should not test it when enabling/disabling ECVF vports.

kernel log: [] refcount_t: underflow; use-after-free. [] WARNING: CPU: 3 PID: 1 at lib/refcount.c:28

refcountwarnsaturate+0x124/0x220

[] Call trace: [] refcountwarnsaturate+0x124/0x220 [] treeputnode+0x164/0x1e0 [mlx5core] [] mlx5destroyflowtable+0x98/0x2c0 [mlx5core] [] eswaclingresstabledestroy+0x28/0x40 [mlx5core] [] eswaclingresslgcycleanup+0x80/0xf4 [mlx5core] [] eswlegacyvportaclcleanup+0x44/0x60 [mlx5core] [] eswvportcleanup+0x64/0x90 [mlx5core] [] mlx5eswvportdisable+0xc0/0x1d0 [mlx5core] [] mlx5eswitchunloadecvfvports+0xcc/0x150 [mlx5core] [] mlx5eswitchdisablesriov+0x198/0x2a0 [mlx5core] [] mlx5devicedisablesriov+0xb8/0x1e0 [mlx5core] [] mlx5sriovdetach+0x40/0x50 [mlx5core] [] mlx5unload+0x40/0xc4 [mlx5core] [] mlx5unloadonedevllocked+0x6c/0xe4 [mlx5core] [] mlx5unloadone+0x3c/0x60 [mlx5core] [] shutdown+0x7c/0xa4 [mlx5core] [] pcideviceshutdown+0x3c/0xa0 [] deviceshutdown+0x170/0x340 [] _dosysreboot+0x1f4/0x2a0 [] _arm64sysreboot+0x2c/0x40 [] invokesyscall+0x78/0x100 [] el0svccommon.constprop.0+0x54/0x184 [] doel0svc+0x30/0xac [] el0svc+0x48/0x160 [] el0t64synchandler+0xa4/0x12c [] el0t64_sync+0x1a4/0x1a8 [] --[ end trace 9c4601d68c70030e ]---(CVE-2025-38109)

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

kernfs: Relax constraint in draining guard

The active reference lifecycle provides the break/unbreak mechanism but the active reference is not truly active after unbreak -- callers don't use it afterwards but it's important for proper pairing of kn->active counting. Assuming this mechanism is in place, the WARN check in kernfsshoulddrainopenfiles() is too sensitive -- it may transiently catch those (rightful) callers between kernfsunbreakactiveprotection() and kernfsput_active() as found out by Chen Ridong:

kernfs_remove_by_name_ns    kernfs_get_active // active=1
__kernfs_remove                   // active=0x80000002
kernfs_drain            ...
wait_event
//waiting (active == 0x80000001)
                kernfs_break_active_protection
                // active = 0x80000001
// continue
                kernfs_unbreak_active_protection
                // active = 0x80000002
...
kernfs_should_drain_open_files
// warning occurs
                kernfs_put_active

To avoid the false positives (mind paniconwarn) remove the check altogether. (This is meant as quick fix, I think active reference break/unbreak may be simplified with larger rework.)(CVE-2025-38282)

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

drm/amd/display: Check dce_hwseq before dereferencing it

[WHAT]

hws was checked for null earlier in dce110blankstream, indicating hws can be null, and should be checked whenever it is used.

(cherry picked from commit 79db43611ff61280b6de58ce1305e0b2ecf675ad)(CVE-2025-38361)

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

x86/sev: Evict cache lines during SNP memory validation

An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation.

CPUID bit Fn8000001FEBX[31] defines the COHERENCYSFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed.

Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCYSFWNO bit is not set, indicating the SNP guest is vulnerable.(CVE-2025-38560)

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

ipv6: prevent infinite loop in rt6nlmsgsize()

While testing prior patch, I was able to trigger an infinite loop in rt6nlmsgsize() in the following place:

listforeachentryrcu(sibling, &f6i->fib6siblings, fib6siblings) { rt6nhnlmsgsize(sibling->fib6nh, &nexthop_len); }

This is because fib6delroute() and fib6addrt2node() uses listdelrcu(), which can confuse rcu readers, because they might no longer see the head of the list.

Restart the loop if f6i->fib6_nsiblings is zero.(CVE-2025-38588)

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

eventpoll: Fix semi-unbounded recursion

Ensure that epoll instances can never form a graph deeper than EPMAXNESTS+1 links.

Currently, eploopcheck_proc() ensures that the graph is loop-free and does some recursion depth checks, but those recursion depth checks don't limit the depth of the resulting tree for two reasons:

• They don't look upwards in the tree.
• If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths").

Essentially, the current recursion depth check in eploopcheck_proc() just serves to prevent it from recursing too deeply while checking for loops.

A more thorough check is done in reversepathcheck() after the new graph edge has already been created; this checks, among other things, that no paths going upwards from any non-epoll file with a length of more than 5 edges exist. However, this check does not apply to non-epoll files.

As a result, it is possible to recurse to a depth of at least roughly 500, tested on v6.15. (I am unsure if deeper recursion is possible; and this may have changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversion problem").)

To fix it:

1. In eploopcheck_proc(), note the subtree depth of each visited node, and use subtree depths for the total depth calculation even when a subtree has already been visited.
2. Add epgetupwardsdepthproc() for similarly determining the maximum depth of an upwards walk.
3. In eploopcheck(), use these values to limit the total path length between epoll nodes to EPMAXNESTS edges.(CVE-2025-38614)

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

net/packet: fix a race in packetsetring() and packet_notifier()

When packetsetring() releases po->bindlock, another thread can run packetnotifier() and process an NETDEV_UP event.

This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packetbind() and packetnotifier()").

There too the packetnotifier NETDEVUP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.

The po->bindlock in packetsetring and packetnotifier precede the introduction of git history.(CVE-2025-38617)

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

rv: Use strings in da monitors tracepoints

Using DA monitors tracepoints with KASAN enabled triggers the following warning:

BUG: KASAN: global-out-of-bounds in dotraceeventraweventeventdamonitor+0xd6/0x1a0 Read of size 32 at addr ffffffffaada8980 by task ... Call Trace: <TASK> [...] dotraceeventraweventeventdamonitor+0xd6/0x1a0 ? _pfxdotraceeventraweventeventdamonitor+0x10/0x10 ? traceeventsncid+0x83/0x200 traceeventsncid+0x163/0x200 [...] The buggy address belongs to the variable: automatonsnep+0x4e0/0x5e0

This is caused by the tracepoints reading 32 bytes _array instead of _string from the automata definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g. the next automaton's data in this case). The error is harmless as, while printing the string, we stop at the null terminator, but it should still be fixed.

Use the __string facilities while defining the tracepoints to avoid reading out of bound memory.(CVE-2025-38636)

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

ice: Fix a null pointer dereference in icecopyandinitpkg()

Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.(CVE-2025-38664)

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

ASoC: core: Check for rtd == NULL in sndsocremovepcmruntime()

sndsocremovepcmruntime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soctplgremovelink() would call sndsocremovepcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.(CVE-2025-38706)

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

drm/amd/display: Add null pointer check in modhdcphdcp1createsession()

The function modhdcphdcp1createsession() calls the function getfirstactive_display(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference.

Add a null pointer check for getfirstactivedisplay() and return MODHDCPSTATUSDISPLAYNOTFOUND if the function return null.

This is similar to the commit c3e9826a2202 ("drm/amd/display: Add null pointer check for getfirstactive_display()").

(cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)(CVE-2025-39675)

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

comedi: Fix use of uninitialized memory in doinsnioctl() and doinsnlistioctl()

syzbot reports a KMSAN kernel-infoleak in do_insn_ioctl(). A kernel buffer is allocated to hold insn->n samples (each of which is an unsigned int). For some instruction types, insn->n samples are copied back to user-space, unless an error code is being returned. The problem is that not all the instruction handlers that need to return data to userspace fill in the whole insn->n samples, so that there is an information leak. There is a similar syzbot report for do_insnlist_ioctl(), although it does not have a reproducer for it at the time of writing.

One culprit is insn_rw_emulate_bits() which is used as the handler for INSN_READ or INSN_WRITE instructions for subdevices that do not have a specific handler for that instruction, but do have an INSN_BITS handler. For INSN_READ it only fills in at most 1 sample, so if insn->n is greater than 1, the remaining insn->n - 1 samples copied to userspace will be uninitialized kernel data.

Another culprit is vm80xx_ai_insn_read() in the "vm80xx" driver. It never returns an error, even if it fails to fill the buffer.

Fix it in do_insn_ioctl() and do_insnlist_ioctl() by making sure that uninitialized parts of the allocated buffer are zeroed before handling each instruction.

Thanks to Arnaud Lecomte for their fix to do_insn_ioctl(). That fix replaced the call to kmalloc_array() with kcalloc(), but it is not always necessary to clear the whole buffer.(CVE-2025-39684)

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

NFS: Fix a race when updating an existing write

After nfslockandjoinrequests() tests for whether the request is still attached to the mapping, nothing prevents a call to nfsinoderemoverequest() from succeeding until we actually lock the page group. The reason is that whoever called nfsinoderemoverequest() doesn't necessarily have a lock on the page group head.

So in order to avoid races, let's take the page group lock earlier in nfslockandjoinrequests(), and hold it across the removal of the request in nfsinoderemove_request().(CVE-2025-39697)

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

smb: client: fix race with concurrent opens in rename(2)

Besides sending the rename request to the server, the rename process also involves closing any deferred close, waiting for outstanding I/O to complete as well as marking all existing open handles as deleted to prevent them from deferring closes, which increases the race window for potential concurrent opens on the target file.

Fix this by unhashing the dentry in advance to prevent any concurrent opens on the target.(CVE-2025-39825)

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

kernfs: Fix UAF in polling when open file is released

A use-after-free (UAF) vulnerability was identified in the PSI (Pressure Stall Information) monitoring mechanism:

BUG: KASAN: slab-use-after-free in psitriggerpoll+0x3c/0x140 Read of size 8 at addr ffff3de3d50bd308 by task systemd/1

psitriggerpoll+0x3c/0x140 cgrouppressurepoll+0x70/0xa0 cgroupfilepoll+0x8c/0x100 kernfsfoppoll+0x11c/0x1c0 epitempoll.isra.0+0x188/0x2c0

Allocated by task 1: cgroupfileopen+0x88/0x388 kernfsfopopen+0x73c/0xaf0 dodentryopen+0x5fc/0x1200 vfsopen+0xa0/0x3f0 doopen+0x7e8/0xd08 pathopenat+0x2fc/0x6b0 dofilp_open+0x174/0x368

Freed by task 8462: cgroupfilerelease+0x130/0x1f8 kernfsdrainopenfiles+0x17c/0x440 kernfsdrain+0x2dc/0x360 kernfsshow+0x1b8/0x288 cgroupfileshow+0x150/0x268 cgrouppressurewrite+0x1dc/0x340 cgroupfile_write+0x274/0x548

Reproduction Steps: 1. Open test/cpu.pressure and establish epoll monitoring 2. Disable monitoring: echo 0 > test/cgroup.pressure 3. Re-enable monitoring: echo 1 > test/cgroup.pressure

The race condition occurs because: 1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroupfilerelease() - Frees of->priv through kernfsdrainopen_files() 2. While epoll still holds reference to the file and continues polling 3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->priv

epolling disable/enable cgroup.pressure fd=open(cpu.pressure) while(1) ... epollwait kernfsfoppoll kernfsgetactive = true echo 0 > cgroup.pressure ... cgroupfileshow kernfsshow // inactive kn kernfsdrainopenfiles cft->release(of); kfree(ctx); ... kernfsgetactive = false echo 1 > cgroup.pressure kernfsshow kernfsactivateone(kn); kernfsfoppoll kernfsgetactive = true cgroupfilepoll psitriggerpoll // UAF ... end: close(fd)

To address this issue, introduce kernfsgetactiveof() for kernfs open files to obtain active references. This function will fail if the open file has been released. Replace kernfsgetactive() with kernfsgetactiveof() to prevent further operations on released file descriptors.(CVE-2025-39881)

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

i40e: remove read access to debugfs files

The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").

Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.

On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.

We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdevops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copyto_user to read beyond the length of the buffer allocated by kzalloc.

A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.

Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.

In order to properly remove the i40edbgnetdevopsbuf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40edbgcommandwrite, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdevops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)

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

ksmbd: smbdirect: verify remainingdatalength respects maxfragmentedrecv_size

This is inspired by the check for dataoffset + datalength.(CVE-2025-39942)

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

mm/ksm: fix flag-dropping behavior in ksm_madvise

syzkaller discovered the following crash: (kernel BUG)

[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUGPAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfdrelease_all+0x3a8/0x460

<snip other registers, drop unreliable trace>

[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfdrelease+0xef/0x1b0 [ 44.620976] _fput+0x3f9/0xb60 [ 44.621240] fputclosesync+0x110/0x210 [ 44.622222] _x64sysclose+0x8f/0x120 [ 44.622530] dosyscall64+0x5b/0x2f0 [ 44.622840] entrySYSCALL64after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227

Kernel panics because it detects UFFD inconsistency during userfaultfdreleaseall(). Specifically, a VMA which has a valid pointer to vma->vmuserfaultfdctx, but no UFFD flags in vma->vm_flags.

The inconsistency is caused in ksmmadvise(): when user calls madvise() with MADVUNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags.

Assuming x8664 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VMMERGEABLE assignment.

VMMERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vmflags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.

Fix it by changing VM_MERGEABLE constant to unsigned long, using the BIT() macro.

Note: other VM* flags are not affected: This only happens to the VMMERGEABLE flag, as the other VM_* flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.

Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM)BUGON()s"), this is no longer a kernel BUG, but a WARNING at the same place:

[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067

but the root-cause (flag-drop) remains the same.

[(CVE-2025-40040)

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

Squashfs: fix uninit-value in squashfsgetparent

Syzkaller reports a "KMSAN: uninit-value in squashfsgetparent" bug.

This is caused by openbyhandle_at() being called with a file handle containing an invalid parent inode number. In particular the inode number is that of a symbolic link, rather than a directory.

Squashfsgetparent() gets called with that symbolic link inode, and accesses the parent member field.

unsigned int parent_ino = squashfs_i(inode)->parent;

Because non-directory inodes in Squashfs do not have a parent value, this is uninitialised, and this causes an uninitialised value access.

The fix is to initialise parent with the invalid inode 0, which will cause an EINVAL error to be returned.

Regular inodes used to share the parent field with the blockliststart field. This is removed in this commit to enable the parent field to contain the invalid inode number 0.(CVE-2025-40049)

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

net: use dstdevrcu() in sksetupcaps()

Use RCU to protect accesses to dst->dev from sksetupcaps() and skdstgsomaxsize().

Also use dstdevrcu() in ip6dstmtumaybeforward(), and ipdstmtumaybeforward().

ip4dsthoplimit() can use dstdevnet_rcu().(CVE-2025-40170)