f2fs: fix ISCHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writes

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

gve: Fix stats report corruption on queue count change

The driver and the NIC share a region in memory for stats reporting. The NIC calculates its offset into this region based on the total size of the stats region and the size of the NIC's stats.

When the number of queues is changed, the driver's stats region is resized. If the queue count is increased, the NIC can write past the end of the allocated stats region, causing memory corruption. If the queue count is decreased, there is a gap between the driver and NIC stats, leading to incorrect stats reporting.

This change fixes the issue by allocating stats region with maximum size, and the offset calculation for NIC stats is changed to match with the calculation of the NIC.

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

nvme-fc: release admin tagset if init fails

nvmefabrics creates an NVMe/FC controller in following path:

nvmfdevwrite() -> nvmfcreatectrl() -> nvmefccreatectrl() -> nvmefcinitctrl()

nvmefcinitctrl() allocates the admin blk-mq resources right after nvmeaddctrl() succeeds. If any of the subsequent steps fail (changing the controller state, scheduling connect work, etc.), we jump to the failctrl path, which tears down the controller references but never frees the admin queue/tag set. The leaked blk-mq allocations match the kmemleak report seen during blktests nvme/fc.

Check ctrl->ctrl.admintagset in the failctrl path and call nvmeremoveadmintagset() when it is set so that all admin queue allocations are reclaimed whenever controller setup aborts.

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

net: liquidio: Fix off-by-one error in VF setupnicdevices() cleanup

In setupnicdevices(), the initialization loop jumps to the label setupnicdevfree on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak.

Fix this by changing the loop to iterate from the current index i down to 0.

Compile tested only. Issue found using code review.

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

net: add proper RCU protection to /proc/net/ptype

Yin Fengwei reported an RCU stall in ptypeseqshow() and provided a patch.

Real issue is that ptypeseqnext() and ptypeseqshow() violate RCU rules.

ptypeseqshow() runs under rcureadlock(), and reads pt->dev to get device name without any barrier.

At the same time, concurrent writers can remove a packettype structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period.

Define ptypeiterstate to carry a dev pointer along seqnetprivate:

struct ptypeiterstate { struct seqnetprivate p; struct netdevice dev; // added in this patch };

We need to record the device pointer in ptypegetidx() and ptypeseqnext() so that ptypeseqshow() is safe against concurrent pt->dev changes.

We also need to add full RCU protection in ptypeseqnext(). (Missing READONCE() when reading list.next values)

Many thanks to Dong Chenchen for providing a repro.

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

net: gro: fix outer network offset

The udp GRO complete stage assumes that all the packets inserted the RX have the encapsulation flag zeroed. Such assumption is not true, as a few H/W NICs can set such flag when H/W offloading the checksum for an UDP encapsulated traffic, the tun driver can inject GSO packets with UDP encapsulation and the problematic layout can also be created via a veth based setup.

Due to the above, in the problematic scenarios, udp4grocomplete() uses the wrong network offset (inner instead of outer) to compute the outer UDP header pseudo checksum, leading to csum validation errors later on in packet processing.

Address the issue always clearing the encapsulation flag at GRO completion time. Such flag will be set again as needed for encapsulated packets by udpgrocomplete().

btrfs: do not free data reservation in fallback from inline due to -ENOSPC

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

perf/core: Fix refcount bug and potential UAF in perfmmap

Syzkaller reported a refcountt: addition on 0; use-after-free warning in perfmmap.

The issue is caused by a race condition between a failing mmap() setup and a concurrent mmap() on a dependent event (e.g., using output redirection).

In perfmmap(), the ringbuffer (rb) is allocated and assigned to event->rb with the mmapmutex held. The mutex is then released to perform maprange().

If maprange() fails, perfmmapclose() is called to clean up. However, since the mutex was dropped, another thread attaching to this event (via inherited events or output redirection) can acquire the mutex, observe the valid event->rb pointer, and attempt to increment its reference count. If the cleanup path has already dropped the reference count to zero, this results in a use-after-free or refcount saturation warning.

Fix this by extending the scope of mmapmutex to cover the maprange() call. This ensures that the ring buffer initialization and mapping (or cleanup on failure) happens atomically effectively, preventing other threads from accessing a half-initialized or dying ring buffer.

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

RDMA/siw: Fix potential NULL pointer dereference in header processing

If siwgethdr() returns -EINVAL before setrxfpducontext(), qp->rxfpdu can be NULL. The error path in siwtcprxdata() dereferences qp->rxfpdu->moreddpsegs without checking, which may lead to a NULL pointer deref. Only check moreddpsegs when rxfpdu is present.

KASAN splat: [ 101.384271] KASAN: null-ptr-deref in range [0x00000000000000c0-0x00000000000000c7] [ 101.385869] RIP: 0010:siwtcprxdata+0x13ad/0x1e50

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

RDMA/umad: Reject negative datalen in ibumadwrite

ibumadwrite computes datalen from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, datalen can become negative and reach ibcreatesendmad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in allocsendrmpplist().

Add an explicit check to reject negative datalen before creating the send buffer.

KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ibcreatesendmad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spraythread/102 [ 211.365867] ibcreatesendmad+0xa01/0x11b0 [ 211.365887] ibumadwrite+0x853/0x1c80

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

fs/xattr: missing fdput() in fremovexattr error path

In the Linux kernel, the fremovexattr() syscall calls fdget() to acquire a file reference but returns early without calling fdput() when strncpyfromuser() fails on the name argument. In multi-threaded processes where fdget() takes the slow path, this permanently leaks one file reference per call, pinning the struct file and associated kernel objects in memory. An unprivileged local user can exploit this to cause kernel memory exhaustion. The issue was inadvertently fixed by commit a71874379ec8 ("xattr: switch to CLASS(fd)").

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

romfs: check sbsetblocksize() return value

romfsfillsuper() ignores the return value of sbsetblocksize(), which can fail if the requested block size is incompatible with the block device's configuration.

This can be triggered by setting a loop device's block size larger than PAGESIZE using ioctl(LOOPSETBLOCKSIZE, 32768), then mounting a romfs filesystem on that device.

When sbsetblocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the device has logicalblocksize=32768, bdevvalidateblocksize() fails because the requested size is smaller than the device's logical block size. sbsetblocksize() returns 0 (failure), but romfs ignores this and continues mounting.

The superblock's block size remains at the device's logical block size (32768). Later, when sbbread() attempts I/O with this oversized block size, it triggers a kernel BUG in foliosetbh():

kernel BUG at fs/buffer.c:1582! BUGON(size > PAGESIZE);

Fix by checking the return value of sbsetblocksize() and failing the mount with -EINVAL if it returns 0.

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

f2fs: fix out-of-bounds access in sysfs attribute read/write

Some f2fs sysfs attributes suffer from out-of-bounds memory access and incorrect handling of integer values whose size is not 4 bytes.

For example: vm:~# echo 65537 > /sys/fs/f2fs/vde/carveout vm:~# cat /sys/fs/f2fs/vde/carveout 65537 vm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgcagethreshold vm:~# cat /sys/fs/f2fs/vde/atgcagethreshold 1

carveout maps to {struct f2fssbinfo}->carveout, which is a 8-bit integer. However, the sysfs interface allows setting it to a value larger than 255, resulting in an out-of-range update.

atgcagethreshold maps to {struct atgcmanagement}->agethreshold, which is a 64-bit integer, but its sysfs interface cannot correctly set values larger than UINTMAX.

The root causes are: 1. sbistore() treats all default values as unsigned int, which prevents updating integers larger than 4 bytes and causes out-of-bounds writes for integers smaller than 4 bytes.

2. f2fssbishow() also assumes all default values are unsigned int, leading to out-of-bounds reads and incorrect access to integers larger than 4 bytes.

This patch introduces {struct f2fsattr}->size to record the actual size of the integer associated with each sysfs attribute. With this information, sysfs read and write operations can correctly access and update values according to their real data size, avoiding memory corruption and truncation.

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

smb: client: split cachedfid bitfields to avoid shared-byte RMW races

isopen, haslease and onlist are stored in the same bitfield byte in struct cachedfid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. orb $mask, addr on x8664), so updating one flag can restore stale values of the others.

A possible interleaving is: CPU1: load old byte (haslease=1, onlist=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | ISOPEN) -> reintroduces cleared bits

To avoid this class of races, convert these flags to separate bool fields.

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

ksmbd: fix infinite loop caused by nextsmb2rcvhdroff reset in error paths

The problem occurs when a signed request fails smb2 signature verification check. In processrequest(), if checksignreq() returns an error, setsmb2rspstatus(work, STATUSACCESSDENIED) is called. setsmb2rspstatus() set work->nextsmb2rcvhdroff as zero. By resetting nextsmb2rcvhdroff to zero, the pointer to the next command in the chain is lost. Consequently, ischainedsmb2message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing handleksmbdwork() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with "bad smb2 signature" messages and high CPU usage.

This patch fixes the issue by changing the return value from SERVERHANDLERCONTINUE to SERVERHANDLERABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.

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

x86/vmware: Fix hypercall clobbers

Fedora QA reported the following panic:

BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmwarehypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmousereportevents+0x13e/0x1b0 psmousehandlebyte+0x15/0x60 ps2interrupt+0x8a/0xd0 ...

because the QEMU VMware mouse emulation is buggy, and clears the top 32 bits of %rdi that the kernel kept a pointer in.

The QEMU vmmouse driver saves and restores the register state in a "uint32t data[6];" and as a result restores the state with the high bits all cleared.

RDI originally contained the value of a valid kernel stack address (0xff5eeb3240003e54). After the vmware hypercall it now contains 0x40003e54, and we get a page fault as a result when it is dereferenced.

The proper fix would be in QEMU, but this works around the issue in the kernel to keep old setups working, when old kernels had not happened to keep any state in %rdi over the hypercall.

In theory this same issue exists for all the hypercalls in the vmmouse driver; in practice it has only been seen with vmwarehypercall3() and vmwarehypercall4(). For now, just mark RDI/RSI as clobbered for those two calls. This should have a minimal effect on code generation overall as it should be rare for the compiler to want to make RDI/RSI live across hypercalls.

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

ALSA: usb-audio: Prevent excessive number of frames

In this case, the user constructed the parameters with maxpacksize 40 for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer size for each data URB is maxpacksize packets, which in this example is 40 6 = 240; When the user performs a write operation to send audio data into the ALSA PCM playback stream, the calculated number of frames is packsize[0] packets = 264, which exceeds the allocated URB buffer size, triggering the out-of-bounds (OOB) issue reported by syzbot [1].

Added a check for the number of single data URB frames when calculating the number of frames to prevent [1].

[1] BUG: KASAN: slab-out-of-bounds in copytourb+0x261/0x460 sound/usb/pcm.c:1487 Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506 Call Trace: copytourb+0x261/0x460 sound/usb/pcm.c:1487 prepareplaybackurb+0x953/0x13d0 sound/usb/pcm.c:1611 prepareoutboundurb+0x377/0xc50 sound/usb/endpoint.c:333

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

net/sched: clsu32: use skbheaderpointercareful()

skbheaderpointer() does not fully validate negative @offset values.

Use skbheaderpointercareful() instead.

GangMin Kim provided a report and a repro fooling u32classify():

BUG: KASAN: slab-out-of-bounds in u32classify+0x1180/0x11b0 net/sched/clsu32.c:221

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

rustbinder: correctly handle FDA objects of length zero

Fix a bug where an empty FDA (fd array) object with 0 fds would cause an out-of-bounds error. The previous implementation used skip == 0 to mean "this is a pointer fixup", but 0 is also the correct skip length for an empty FDA. If the FDA is at the end of the buffer, then this results in an attempt to write 8-bytes out of bounds. This is caught and results in an EINVAL error being returned to userspace.

The pattern of using skip == 0 as a special value originates from the C-implementation of Binder. As part of fixing this bug, this pattern is replaced with a Rust enum.

I considered the alternate option of not pushing a fixup when the length is zero, but I think it's cleaner to just get rid of the zero-is-special stuff.

The root cause of this bug was diagnosed by Gemini CLI on first try. I used the following prompt:

There appears to be a bug in @drivers/android/binder/thread.rs where the Fixups oob bug is triggered with 316 304 316 324. This implies that we somehow ended up with a fixup where buffer A has a pointer to buffer B, but the pointer is located at an index in buffer A that is out of bounds. Please investigate the code to find the bug. You may compare with @drivers/android/binder.c that implements this correctly.

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

ALSA: aloop: Fix racy access at PCM trigger

The PCM trigger callback of aloop driver tries to check the PCM state and stop the stream of the tied substream in the corresponding cable. Since both check and stop operations are performed outside the cable lock, this may result in UAF when a program attempts to trigger frequently while opening/closing the tied stream, as spotted by fuzzers.

For addressing the UAF, this patch changes two things: - It covers the most of code in loopbackcheckformat() with cable->lock spinlock, and add the proper NULL checks. This avoids already some racy accesses. - In addition, now we try to check the state of the capture PCM stream that may be stopped in this function, which was the major pain point leading to UAF.

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

net: usb: r8152: fix resume reset deadlock

rtl8152 can trigger device reset during reset which potentially can result in a deadlock:

DPM device timeout after 10 seconds; 15 seconds until panic Call Trace: <TASK> schedule+0x483/0x1370 schedulepreemptdisabled+0x15/0x30 mutexlockcommon+0x1fd/0x470 rtl8152setmacaddress+0x80/0x1f0 devsetmacaddress+0x7f/0x150 rtl8152postreset+0x72/0x150 usbresetdevice+0x1d0/0x220 rtl8152resume+0x99/0xc0 usbresumeinterface+0x3e/0xc0 usbresumeboth+0x104/0x150 usbresume+0x22/0x110

The problem is that rtl8152 resume calls reset under tp->control mutex while reset basically re-enters rtl8152 and attempts to acquire the same tp->control lock once again.

Reset INACCESSIBLE device outside of tp->control mutex scope to avoid recursive mutexlock() deadlock.

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

nvmet-tcp: fixup hang in nvmettcplistendataready()

When the socket is closed while in TCPLISTEN a callback is run to flush all outstanding packets, which in turns calls nvmettcplistendataready() with the skcallbacklock held. So we need to check if we are in TCPLISTEN before attempting to get the skcallbacklock() to avoid a deadlock.

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

platform/x86: toshibahaps: Fix memory leaks in add/remove routines

toshibahapsadd() leaks the haps object allocated by it if it returns an error after allocating that object successfully.

toshibahapsremove() does not free the object pointed to by toshibahaps before clearing that pointer, so it becomes unreachable allocated memory.

Address these memory leaks by using devmkzalloc() for allocating the memory in question.

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

dmaengine: mmppdma: Fix race condition in mmppdmaresidue()

Add proper locking in mmppdmaresidue() to prevent use-after-free when accessing descriptor list and descriptor contents.

The race occurs when multiple threads call txstatus() while the tasklet on another CPU is freeing completed descriptors:

CPU 0 CPU 1 ----- ----- mmppdmatxstatus() mmppdmaresidue() -> NO LOCK held listforeachentry(sw, ..) DMA interrupt dmadotasklet() -> spinlock(&desclock) listmove(sw->node, ...) spinunlock(&desclock) | dmapoolfree(sw) <- FREED! -> access sw->desc <- UAF!

This issue can be reproduced when running dmatest on the same channel with multiple threads (threadsperchan > 1).

Fix by protecting the chainrunning list iteration and descriptor access with the chan->desclock spinlock.

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

mptcp: fix race in mptcppmnlflushaddrsdoit()

syzbot and Eulgyu Kim reported crashes in mptcppmnlgetlocalid() and/or mptcppmnlisbackup()

Root cause is listspliceinit() in mptcppmnlflushaddrsdoit() which is not RCU ready.

listspliceinitrcu() can not be called here while holding pernet->lock spinlock.

Many thanks to Eulgyu Kim for providing a repro and testing our patches.

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

rocker: fix memory leak in rockerworldportpostfini()

In rockerworldportpreinit(), rockerport->wpriv is allocated with kzalloc(wops->portprivsize, GFPKERNEL). However, in rockerworldportpostfini(), the memory is only freed when wops->portpostfini callback is set:

if (!wops->portpostfini) return; wops->portpostfini(rockerport); kfree(rockerport->wpriv);

Since rockerofdpaops does not implement portpostfini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpaport) bytes per port on every device removal.

Fix this by always calling kfree(rockerport->wpriv) regardless of whether the portpostfini callback exists.

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

perf: sched: Fix perf crash with new isusertask() helper

In order to do a user space stacktrace the current task needs to be a user task that has executed in user space. It use to be possible to test if a task is a user task or not by simply checking the taskstruct mm field. If it was non NULL, it was a user task and if not it was a kernel task.

But things have changed over time, and some kernel tasks now have their own mm field.

An idea was made to instead test PFKTHREAD and two functions were used to wrap this check in case it became more complex to test if a task was a user task or not[1]. But this was rejected and the C code simply checked the PFKTHREAD directly.

It was later found that not all kernel threads set PFKTHREAD. The io-uring helpers instead set PFUSERWORKER and this needed to be added as well.

But checking the flags is still not enough. There's a very small window when a task exits that it frees its mm field and it is set back to NULL. If perf were to trigger at this moment, the flags test would say its a user space task but when perf would read the mm field it would crash with at NULL pointer dereference.

Now there are flags that can be used to test if a task is exiting, but they are set in areas that perf may still want to profile the user space task (to see where it exited). The only real test is to check both the flags and the mm field.

Instead of making this modification in every location, create a new isusertask() helper function that does all the tests needed to know if it is safe to read the user space memory or not.

[1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/

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

gpio: virtuser: fix UAF in configfs release path

The gpio-virtuser configfs release path uses guard(mutex) to protect the device structure. However, the device is freed before the guard cleanup runs, causing mutexunlock() to operate on freed memory.

Specifically, gpiovirtuserdeviceconfiggrouprelease() destroys the mutex and frees the device while still inside the guard(mutex) scope. When the function returns, the guard cleanup invokes mutexunlock(&dev->lock), resulting in a slab use-after-free.

Limit the mutex lifetime by using a scopedguard() only around the activation check, so that the lock is released before mutexdestroy() and kfree() are called.

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

nvmet: fix race in nvmetbiodone() leading to NULL pointer dereference

There is a race condition in nvmetbiodone() that can cause a NULL pointer dereference in blkcgroupbiostart():

1. nvmetbiodone() is called when a bio completes 2. nvmetreqcomplete() is called, which invokes req->ops->queueresponse(req) 3. The queueresponse callback can re-queue and re-submit the same request 4. The re-submission reuses the same inlinebio from nvmetreq 5. Meanwhile, nvmetreqbioput() (called after nvmetreqcomplete) invokes biouninit() for inlinebio, which sets bio->biblkg to NULL 6. The re-submitted bio enters submitbionoacctnocheck() 7. blkcgroupbiostart() dereferences bio->biblkg, causing a crash:

BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode RIP: 0010:blkcgroupbiostart+0x10/0xd0 Call Trace: submitbionoacctnocheck+0x44/0x250 nvmetbdevexecuterw+0x254/0x370 [nvmet] processonework+0x193/0x3c0 workerthread+0x281/0x3a0

Fix this by reordering nvmetbiodone() to call nvmetreqbioput() BEFORE nvmetreqcomplete(). This ensures the bio is cleaned up before the request can be re-submitted, preventing the race condition.

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

btrfs: zlib: fix the folio leak on S390 hardware acceleration

[BUG] After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration buffer preparation"), we no longer release the folio of the page cache of folio returned by btrfscompressfilemapgetfolio() for S390 hardware acceleration path.

[CAUSE] Before that commit, we call kumaplocal() and folioput() after handling each folio.

Although the timing is not ideal (it release previous folio at the beginning of the loop, and rely on some extra cleanup out of the loop), it at least handles the folio release correctly.

Meanwhile the refactored code is easier to read, it lacks the call to release the filemap folio.

[FIX] Add the missing folioput() for copydataintobuffer().