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

perf/aux: Fix page UAF in maprange()

maprange() reads rb->auxpages[], rb->auxnrpages and rb->auxpgoff via perfmmaptopage() while holding only event->mmapmutex. Those fields are serialized by rb->auxmutex, and mmapmutex is per event.

Thus, two events sharing one rb via PERFEVENTIOCSETOUTPUT can race rballocaux() with maprange(), leading to a page-UAF scenario as follows:

CPU 0 CPU 1 ===== ===== rballocaux() maprange() [1]: allocate rb->auxpages[0] [2]: rb->auxnrpages++ [3]: perfmmaptopage() returns rb->auxpages[0] [4]: map it as VMPFNMAP [5]: rb->auxpgoff = 1

munmap the page [6]: free rb->auxpages[0]

Pages mapped as VMPFNMAP have no refcount protection, so CPU 1 holds a mapping to a freed physical frame.

Fix this by taking rb->auxmutex across the page walk in maprange().

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

fuse-uring: Avoid queue->stopped races and set/read that value under lock

There are several readers of queue->stopped that check the value under lock, but fuseuringcommitfetch() did not and actually the value was not set under the lock in fuseuringabortendrequests() either. Especially in fuseuringcommitfetch it is important to check under a lock, because due to races 'struct fusereq' might be freed with fuserequestend, but another thread/cpu might already do teardown work.

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

fuse-uring: Avoid use-after-free in fuseuringasyncstopqueues

fuseuringasyncstopqueues() might run when the last reference on ring->queuerefs was already dropped.

In order to avoid an early destruction a reference on struct fuseconn is now taken before starting fuseuringasyncstopqueues() and that reference is only released when that delayed work queue terminates.

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

fuse-uring: make a fusereq on SQE commit only findable after memcpy

Bad userspace might try to trick us and send commit SQEs request unique / commit-id of requests that are not even send to fuse-server (iouringcmddone() not called) yet.

fuseuringcommitfetch() ends the fuse request when the ring entry has a wrong state, but that could have caused a use-after-free with the memcpy operations in fuseuringsendintask(). In order to avoid such races the call of fuseuringaddtopq() is moved after the copy operations and just before completing the io-uring request - malicious userspace cannot find the request anymore until all prepration work in fuse-client/kernel is completed.

This also moves fuseuringaddtopq() a bit up in the code to avoid a forward declaration. Also not with a preparation commit, to make it easier to back port to older kernels.

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

virt: sev-guest: Explicitly leak pages in unknown state

When setmemory{encrypted,decrypted}() fail, the user cannot know at which point the function failed, meaning that the pages are left in an unknown state from the point of view of the caller.

Since the pages may be left in an unencrypted state, they are not suitable for general use, and cannot be returned safely to the buddy allocator. Avoid the issue by never freeing the pages, and then do the proper accounting by calling snpleakpages().

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

fprobe: Fix unregisterfprobe() to wait for RCU grace period

Commit 4346ba1604093 ("fprobe: Rewrite fprobe on function-graph tracer") changed fprobe to register struct fprobe to an rcu-hlist, but it forgot to wait for RCU GP. Thus there can be use-after-free if the fprobe is released right after unregistering. This can be happened on fprobe event and sample module code.

To fix this issue, add synchronizercu() in unregisterfprobe().

Note that BPF is OK because fprobe is used as a part of bpfkprobemultilink. This unregisters its fprobe in bpfkprobemultilinkrelease() and it is deallocated via bpfkprobemultilinkdealloc(), which is invoked from bpflinkdeferdeallocrcugp() RCU callback.

For BPF, this also introduced unregisterfprobeasync() which does NOT wait for RCU grace priod.

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

afs: Fix the locking used by afsgetlink()

The afs filesystem in the kernel doesn't do locking correctly for symbolic links. There are a number of problems:

(1) It doesn't do any locking around afsreadsingle() to prevent races between multiple ->getlink() calls, thereby allowing the possibility of leaks.

(2) It doesn't use RCU barriering when accessing the buffer pointers during RCU pathwalk.

(3) It can race with another thread updating the contents of the symlink if a third party updated it on the server.

Fix this by the following means:

(0) Move symlink handling into its own file as this makes it more complicated.

(1) Take the validatelock around afsreadsingle() to prevent races between multiple ->getlink() calls.

(2) Keep a separate copy of the symlink contents with an rcuhead. This is always going to be a lot smaller than a page, so it can be kmalloc'd and save quite a bit of memory. It also needs a refcount for non-RCU pathwalk.

(3) Split the symlink read and write-to-cache routines in afs from those for directories.

(4) Discard the I/O buffer as soon as the write-to-cache completes as this is a full page (plus a folioqueue).

(5) If there's no cache, discard the I/O buffer immediately after reading and copying if there is no cache.

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

tee: optee: prevent use-after-free when the client exits before the supplicant

Commit 70b0d6b0a199 ("tee: optee: Fix supplicant wait loop") made the client wait as killable so it can be interrupted during shutdown or after a supplicant crash. This changes the original lifetime expectations: the client task can now terminate while the supplicant is still processing its request.

If the client exits first it removes the request from its queue and kfree()s it, while the request ID remains in supp->idr. A subsequent lookup on the supplicant path then dereferences freed memory, leading to a use-after-free.

Serialise access to the request with supp->mutex:

Hold supp->mutex in opteesupprecv() and opteesuppsend() while looking up and touching the request. Let opteesuppthrdreq() notice that the client has terminated and signal opteesuppsend() accordingly.

With these changes the request cannot be freed while the supplicant still has a reference, eliminating the race.

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

xfrm: iptfs: fix use-after-free on firstskb in inputprocesspayload

inputprocesspayload() stores firstskb into xtfs->ranewskb under droplock when starting partial reassembly, then unlocks and breaks out of the processing loop. The post-loop check reads xtfs->ranewskb without the lock to decide whether firstskb is still owned:

if (firstskb && firstiplen && !defer && firstskb != xtfs->ranewskb)

Between spinunlock and this read, a concurrent CPU running iptfsreassemcont() (or the droptimer hrtimer) can complete reassembly, NULL xtfs->ranewskb, and free the skb. The check then evaluates firstskb != NULL as true, and pskbtrim/ipsummed/consumeskb operate on the freed skb — a use-after-free in skbuffheadcache.

Replace the unlocked read with a local bool that records whether firstskb was handed to the reassembly state in the current call. The flag is set after the existing spinunlock, before the break, using the pointer equality that is stable at that point (firstskb == skb iff firstskb was stored in ranewskb).

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

virt: sev-guest: Do not use host-controlled page order in cleanup path

When issuing an extended guest request (SVMVMGEXITEXTGUESTREQUEST), getextreport() allocates a buffer to retrieve a certificate blob from the host, keeping track of its size in reportreq->certslen.

However, the host may return SNPGUESTVMMERRINVALIDLEN, indicating an invalid buffer size, as well as the expected length of such buffer. getextreport() subsequently updates reportreq->certslen with the host-controlled value, and cleans up the buffer by computing a page order from such value. This is incorrect, as the host-provided length may not match the page order of the original allocation, potentially resulting in corruption in the page allocator.

Fix this by using allocpagesexact() instead, and reusing @npages to compute the size passed to freepagesexact(). For consistency, also use @npages to compute the size when allocating the pages, even though this last change has no functional effect.

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

bpf: Fix a potential use-after-free of BTF object

Refcounting in the checkpseudobtfid() function is incorrect: the checkpseudobtfid() function might get called with a zero refcounted btf. Fix this, and patch related code accordingly.

v3: rephrase a comment (AI) v2: fix a refcount leak introduced in v1 (AI)

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

accel/amdxdna: Hold mm structure across iommusvaunbinddevice()

Some tests trigger a crash in iommusvaunbinddevice() due to accessing iommumm after the associated mm structure has been freed.

Fix this by taking an explicit reference to the mm structure after successfully binding the device, and releasing it only after the device is unbound. This ensures the mm remains valid for the entire SVA bind/unbind lifetime.

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

bpf: Fix memory access flags in helper prototypes

After commit 37cce22dbd51 ("bpf: verifier: Refactor helper access type tracking"), the verifier started relying on the access type flags in helper function prototypes to perform memory access optimizations.

Currently, several helper functions utilizing ARGPTRTOMEM lack the corresponding MEMRDONLY or MEMWRITE flags. This omission causes the verifier to incorrectly assume that the buffer contents are unchanged across the helper call. Consequently, the verifier may optimize away subsequent reads based on this wrong assumption, leading to correctness issues.

For bpfgetstackprotorawtp, the original MEMRDONLY was incorrect since the helper writes to the buffer. Change it to ARGPTRTOUNINITMEM which correctly indicates write access to potentially uninitialized memory.

Similar issues were recently addressed for specific helpers in commit ac44dcc788b9 ("bpf: Fix verifier assumptions of bpfdpath's output buffer") and commit 2eb7648558a7 ("bpf: Specify access type of bpfsysctlgetname args").

Fix these prototypes by adding the correct memory access flags.

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

ima: Fix stack-out-of-bounds in isbprmcredsforexec()

KASAN reported a stack-out-of-bounds access in imaappraisemeasurement from isbprmcredsforexec:

BUG: KASAN: stack-out-of-bounds in imaappraisemeasurement+0x12dc/0x16a0 Read of size 1 at addr ffffc9000160f940 by task sudo/550 The buggy address belongs to stack of task sudo/550 and is located at offset 24 in frame: imaappraisemeasurement+0x0/0x16a0 This frame has 2 objects: [48, 56) 'file' [80, 148) 'hash'

This is caused by using containerof on the file pointer. This offset calculation is what triggers the stack-out-of-bounds error.

In order to fix this, pass in a bprmischeck boolean which can be set depending on how processmeasurement is called. If the caller has a linuxbinprm pointer and the function is BPRMCHECK we can determine ischeck and set it then. Otherwise set it to false.

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

spi: rockchip-sfc: Fix double-free in remove() callback

The driver uses devmspiregistercontroller() for registration, which automatically unregisters the controller via devm cleanup when the device is removed. The manual call to spiunregistercontroller() in the remove() callback can lead to a double-free.

And to make sure controller is unregistered before DMA buffer is unmapped, switch to use spiregistercontroller() in probe().

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

mm/damon/core: clear walkcontrol on inactive context in damoswalk()

damoswalk() sets ctx->walkcontrol to the caller-provided control structure before checking whether the context is running. If the context is inactive (damonisrunning() returns false), the function returns -EINVAL without clearing ctx->walkcontrol. This leaves a dangling pointer to a stack-allocated structure that will be freed when the caller returns.

This is structurally identical to the bug fixed in commit f9132fbc2e83 ("mm/damon/core: remove callcontrol in inactive contexts") for damoncall(), which had the same pattern of linking a control object and returning an error without unlinking it.

The dangling walkcontrol pointer can cause: 1. Use-after-free if the context is later started and kdamond    dereferences ctx->walkcontrol (e.g., in damoswalkcancel()    which writes to control->canceled and calls complete()) 2. Permanent -EBUSY from subsequent damoswalk() calls, since the    stale pointer is non-NULL

Nonetheless, the real user impact is quite restrictive. The use-after-free is impossible because there is no damoswalk() callers who starts the context later. The permanent -EBUSY can actually confuse users, as DAMON is not running. But the symptom is kept only while the context is turned off. Turning it on again will make DAMON internally uses a newly generated damonctx object that doesn't have the invalid damoswalkcontrol pointer, so everything will work fine again.

Fix this by clearing ctx->walkcontrol under walkcontrollock before returning -EINVAL, mirroring the fix pattern from f9132fbc2e83.

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

arm64: dts: qcom: monaco: Reserve full Gunyah metadata region

We observe spurious "Synchronous External Abort" exceptions (ESR=0x96000010) and kernel crashes on Monaco-based platforms. These faults are caused by the kernel inadvertently accessing hypervisor-owned memory that is not properly marked as reserved.

From boot log, The Qualcomm hypervisor reports the memory range at 0x91a80000 of size 0x80000 (512 KiB) as hypervisor-owned: qheehypassignremovememory: 0x91a80000/0x80000 -> ret 0

However, the EFI memory map provided by firmware only reserves the subrange 0x91a40000–0x91a87fff (288 KiB). The remaining portion (0x91a88000–0x91afffff) is incorrectly reported as conventional memory (from efi debug): efi: 0x000091a40000-0x000091a87fff [Reserved...] efi: 0x000091a88000-0x0000938fffff [Conventional...]

As a result, the allocator may hand out PFNs inside the hypervisor owned region, causing fatal aborts when the kernel accesses those addresses.

Add a reserved-memory carveout for the Gunyah hypervisor metadata at 0x91a80000 (512 KiB) and mark it as no-map so Linux does not map or allocate from this area.

For the record: Hyp version: gunyah-e78adb36e debug (2025-11-17 05:38:05 UTC) UEFI Ver: 6.0.260122.BOOT.MXF.1.0.c1-00449-KODIAKLA-1

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

mailbox: mchp-ipc-sbi: fix out-of-bounds access in mchpipcgetclusteraggrirq()

The clustercfg array is dynamically allocated to hold per-CPU configuration structures, with its size based on the number of online CPUs. Previously, this array was indexed using hartid, which may be non-contiguous or exceed the bounds of the array, leading to out-of-bounds access. Switch to using cpuid as the index, as it is guaranteed to be within the valid range provided by foreachonlinecpu().

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

xfrm: iptfs: only publish modedata after clone setup

iptfsclonestate() stores x->modedata before allocating the reorder window. If that allocation fails, the code frees the cloned state and returns -ENOMEM, leaving x->modedata pointing at freed memory.

The xfrm clone unwind later runs destroystate() through x->modedata, so the failed clone path tears down IPTFS state that clonestate() already freed.

Keep the cloned IPTFS state private until all allocations succeed so failed clones leave x->modedata unset. The destroy path already handles a NULL modedata pointer.

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

dmaengine: idxd: Fix possible invalid memory access after FLR

In the case that the first Function Level Reset (FLR) concludes correctly, but in the second FLR the scratch area for the saved configuration cannot be allocated, it's possible for a invalid memory access to happen.

Always set the deallocated scratch area to NULL after FLR completes.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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

Bluetooth: L2CAP: Fix use-after-free in l2capunregisteruser

After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hcichandel"), l2capconndel() uses conn->lock to protect access to conn->users. However, l2capregisteruser() and l2capunregisteruser() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2capconndel().

This can lead to use-after-free and list corruption bugs, as reported by syzbot.

Fix this by changing l2capregisteruser() and l2capunregisteruser() to use conn->lock instead of hcidevlock(), ensuring consistent locking for the l2capconn structure.

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

iptunnel: adapt iptunnelxmitstats() to NETDEVPCPUSTATDSTATS

Blamed commits forgot that vxlan/geneve use udptunnel[6]xmitskb() which call iptunnelxmitstats().

iptunnelxmitstats() was assuming tunnels were only using NETDEVPCPUSTATTSTATS.

@syncp offset in pcpuswnetstats and pcpudstats is different.

32bit kernels would either have corruptions or freezes if the syncp sequence was overwritten.

This patch also moves pcpustattype closer to dev->{t,d}stats to avoid a potential cache line miss since iptunnelxmitstats() needs to read it.

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

KVM: arm64: Fix ID register initialization for non-protected pKVM guests

In protected mode, the hypervisor maintains a separate instance of the kvm structure for each VM. For non-protected VMs, this structure is initialized from the host's kvm state.

Currently, pkvminitfeaturesfromhost() copies the KVMARCHFLAGIDREGSINITIALIZED flag from the host without the underlying idregs data being initialized. This results in the hypervisor seeing the flag as set while the ID registers remain zeroed.

Consequently, kvmhasfeat() checks at EL2 fail (return 0) for non-protected VMs. This breaks logic that relies on feature detection, such as ctxthastcrx() for TCR2EL1 support. As a result, certain system registers (e.g., TCR2EL1, PIREL1, POREL1) are not saved/restored during the world switch, which could lead to state corruption.

Fix this by explicitly copying the ID registers from the host kvm to the hypervisor kvm for non-protected VMs during initialization, since we trust the host with its non-protected guests' features. Also ensure KVMARCHFLAGIDREGSINITIALIZED is cleared initially in pkvminitfeaturesfromhost so that vmcopyidregs can properly initialize them and set the flag once done.

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

accel/amdxdna: Validate command buffer payload count

The count field in the command header is used to determine the valid payload size. Verify that the valid payload does not exceed the remaining buffer space.

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:

cgroup/dmem: avoid pool UAF

An UAF issue was observed:

BUG: KASAN: slab-use-after-free in pagecounteruncharge+0x65/0x150 Write of size 8 at addr ffff888106715440 by task insmod/527

CPU: 4 UID: 0 PID: 527 Comm: insmod 6.19.0-rc7-next-20260129+ #11 Tainted: [O]=OOTMODULE Call Trace: <TASK> dumpstacklvl+0x82/0xd0 kasanreport+0xca/0x100 kasancheckrange+0x39/0x1c0 pagecounteruncharge+0x65/0x150 dmemcgroupuncharge+0x1f/0x260

Allocated by task 527:

Freed by task 0:

The buggy address belongs to the object at ffff888106715400 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 64 bytes inside of freed 512-byte region [ffff888106715400, ffff888106715600)

The buggy address belongs to the physical page:

Memory state around the buggy address: ffff888106715300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888106715380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888106715400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888106715480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888106715500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

The issue occurs because a pool can still be held by a caller after its associated memory region is unregistered. The current implementation frees the pool even if users still hold references to it (e.g., before uncharge operations complete).

This patch adds a reference counter to each pool, ensuring that a pool is only freed when its reference count drops to zero.

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

netfs: Fix early read unlock of page with EOF in middle

The read result collection for buffered reads seems to run ahead of the completion of subrequests under some circumstances, as can be seen in the following log snippet:

9pclientres: client 18446612686390831168 response P9TREAD tag 0 err 0 ... netfssreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0 ... netfscollectfolio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2 netfsfolio: i=157f3 ix=00004-00004 read-done netfsfolio: i=157f3 ix=00004-00004 read-unlock netfscollectfolio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfsfolio: i=157f3 ix=00005-00005 read-done netfsfolio: i=157f3 ix=00005-00005 read-unlock ... netfscollectstream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfscollectstate: R=00001b55 col=5fb2 cln=6000 n=c netfscollectstream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfscollectstate: R=00001b55 col=5fb2 cln=6000 n=8 ... netfssreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0 netfssreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0

The 'cto=5fb2' indicates the collected file pos we've collected results to so far - but we still have 0x4e more bytes to go - so we shouldn't have collected folio ix=00005 yet. The 'ZERO' subreq that clears the tail happens after we unlock the folio, allowing the application to see the uncleared tail through mmap.

The problem is that netfsreadunlockfolios() will unlock a folio in which the amount of read results collected hits EOF position - but the ZERO subreq lies beyond that and so happens after.

Fix this by changing the end check to always be the end of the folio and never the end of the file.

In the future, I should look at clearing to the end of the folio here rather than adding a ZERO subreq to do this. On the other hand, the ZERO subreq can run in parallel with an async READ subreq. Further, the ZERO subreq may still be necessary to, say, handle extents in a ceph file that don't have any backing store and are thus implicitly all zeros.

This can be reproduced by creating a file, the size of which doesn't align to a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something like:

xfsio -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \ -c "mread -v 0 0x6000" /xfstest.test/x

The last 0x4e bytes should all be 00, but if the tail hasn't been cleared yet, you may see rubbish there. This can be reproduced with kafs by modifying the kernel to disable the call to netfsreadsubreqprogress() and to stop afsissueread() from doing the async call for NETFSREADAHEAD. Reproduction can be made easier by inserting an mdelay(100) in netfsissueread() for the ZERO-subreq case.

AFS and CIFS are normally unlikely to show this as they dispatch READ ops asynchronously, which allows the ZERO-subreq to finish first. 9P's READ op is completely synchronous, so the ZERO-subreq will always happen after. It isn't seen all the time, though, because the collection may be done in a worker thread.

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

zram: fix slot write race condition

Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this:

CPU0 CPU1 zramslotlock() zsfree(handle) zramslotlock() zramslotlock() zsfree(handle) zramslotlock()

compress compress handle = zsmalloc() handle = zsmalloc() zramslotlock zramsethandle(handle) zramslotlock zramslotlock zramsethandle(handle) zramslotlock

Either CPU0 or CPU1 zsmalloc handle will leak because zsfree() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope.

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

hsr: hold rcu and dev lock for hsrgetportndev

hsrgetportndev calls hsrforeachport, which need to hold rcu lock. On the other hand, before return the port device, we need to hold the device reference to avoid UaF in the caller function.