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

KVM: x86/mmu: Check write tracking in all address spaces

kvmgfniswritetracked() checks only the supplied memslot, but page tracking is per-address-space and shadow pages are shared across all address spaces. With SMM, a GFN can therefore be write-tracked in one address space and appear untracked through the other.

Check the supplied slot first, then the slot for the other address space. This ensures all callers honor write tracking regardless of the active address space. In particular, it prevents mmutrytounsyncpages() from marking an upper-level shadow page unsync and eventually triggering the BUG in ptelistremove().

[invert direction of the conditional. - Paolo]

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

cgroup: Avoid iteration of dying tasks with zero refcount

The commit 260fbcb92bbea ("cgroup: Move dyingtasks cleanup from cgrouptaskrelease() to cgrouptaskfree()") extended the lifetime of tasks on the dyingtasks list. The iterators have provision to go through dyingtasks because of dying threadgroup leaders or explicit CSSTASKITERWITHDEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgrouptaskrelease()/puttaskstructrcuuser()). The tasks after cgrouptaskrelease() and before cgrouptaskfree() are subject to race when they may or may not have ->usage count > 0.

The race window is between csstaskiternext() invocations when csssetlock is released and we may arrive at a new ->taskpos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, puttaskstructrcucb() is already imminent and the returned taskstruct would could be used after free.)

As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration.

The repeat: loop in csstaskiteradvance() doesn't consider ->usage count, so add a new loop to csstaskiternext() to skip de-used tasks on the dyinglist.

Rough illustration of the possible race

R (reader of cgroup.procs) T (thread) L (group leader) --------------------------------- -------------------------------- -------------------------------- L exits, signal->live > 0 cgrouptaskdead(L) csssetskiptaskiters() // skips only cset->tasks listaddtail(&L->cglist, &cset->dyingtasks) csstaskiternext() take csssetlock csstaskiteradvance() leader && signal->live != 0 => it->taskpos = &L->cglist release csssetlock T exits --signal->live == 0 cgrouptaskdead(T) // csssetlock releasetask(T) cgrouptaskrelease(T) releasetask(L) // zapleader cgrouptaskrelease(L) puttaskstructrcuuser(L) ...RCU... puttaskstruct(L) L->usage = 0 / L still on dyingtasks / ...RCU... puttaskstruct(L) csstaskiternext() // another iteration take csssetlock it->taskpos = &L->cglist gettaskstruct(L) => addition on 0 drop csssetlock cgrouptaskfree(L) csssetskiptaskiters() // dying skip comes too late freetask(L) cgroupprocsshow() taskpidvnr(L)

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

xfrm: hold dev ref until after transportfinish NFHOOK

After async crypto completes, xfrminputresume() calls devput() immediately on re-entry before the skb reaches transportfinish. The skb->dev pointer is then used inside NFHOOK and its okfn, which can race with device teardown.

Remove the devput from the async resumption entry and instead drop the reference after the NFHOOK call in transportfinish, using a saved device pointer since NFHOOK may consume the skb. This covers NFDROP, NFQUEUE and NFSTOLEN paths that skip the okfn.

For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.

btrfs: fix transaction use-after-free in raid stripe insertion

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

net: bcmasp: clear txcb->last before writing each descriptor

bcmaspxmit() only wrote txcb->last = true for the final fragment of an SKB; non-final fragments left the field untouched. If a descriptor slot was reused while it still held a stale true from a previous SKB (possible when txspbringfull() underreported fullness), bcmasptxreclaim() would see last == true mid-SKB and call devconsumeskbany() prematurely, freeing the skbuff while its remaining fragments were still in flight.

Unconditionally clear txcb->last before the conditional set so every descriptor slot starts from a known false state regardless of what a prior transmission left behind.

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

mlxsw: spectrumptp: Fix napigroreceive() call from GC workqueue context

Currently mlxswsp1ptphtgccollect() is run from the PTP garbage-collection workqueue, rather than the NAPI poll context. For any unmatched PTP entries carrying an SKB, it calls mlxswsp1ptpunmatchedfinish() -> mlxswsp1ptppacketfinish(). For ingress packets, this calls mlxswsprxlistenernomarkfunc(). The end of that function is the following:

skb->protocol = ethtypetrans(skb, skb->dev); napigroreceive(mlxswskbcb(skb)->rxmdinfo.napi, skb);

The napi pointer is one that was placed in the SKB control block when the trapped packet was received in the NAPI context. Later, when the GC reaps the unmatched entry (up to MLXSWSP1PTPHTGCTIMEOUT later), the call to napigroreceive() mutates the NAPI instance's GRO list, which is unsafe if the poll is running concurrently on another CPU.

In mlxswsp1ptphtgccollect(), localbhdisable() is called to prevent softirq processing, but this only applies to the local CPU. Additionally, its comment is stale. It states that mlxswsp1ptpunmatchedfinish() invokes netifreceiveskb(). This has not been accurate since the referenced commit; this patch makes that comment accurate again. mlxswpcinapidevsinit() calls netifthreadedenable() on the NAPI RX netdevice without any conditions. The NAPI instance's poll, which may be running concurrent to the GC, is running as an independently-scheduled kthread which may be on a different CPU. The call to localbhdisable() does not guard against this.

If a tx-timestamp timeout produces an unmatched entry (which can be easily reproduced by running ptp4l and waiting for a port to reach the UNCALIBRATED/SLAVE state) while the owning NAPI thread is in the middle of a poll on another CPU, both sides mutate the GRO list concurrently, as shown below:

[39.846] port 1 (swp1): MASTER to UNCALIBRATED on RSSLAVE listadd corruption. next->prev should be prev (ffff8d620faf4138), but was ffff8d624150f700. (next=ffff8d620faf4138). kernel BUG at lib/listdebug.c:29! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 1 UID: 0 PID: 539 Comm: napi/mlxswrx-0 Not tainted 6.18.48 #1-NixOS PREEMPT(lazy) Hardware name: Mellanox Technologies Ltd. MSN2410/VMOD0001, BIOS 4.6.5 09/13/2018 RIP: 0010:listaddvalidorreport+0x79/0xb0 RSP: 0018:ffffcdf8c0f27c08 EFLAGS: 00010246 RAX: 0000000000000075 RBX: ffff8d624150fd00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8d6315d1e540 RBP: ffff8d620faf4070 R08: 0000000000000000 R09: 00000000ffffdfff R10: ffffffffa5c60fe0 R11: ffffcdf8c0f27ab8 R12: 0000000000000003 R13: 000000000000003d R14: 00000000000001bc R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8d636f63f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562689a60c24 CR3: 000000015f224004 CR4: 00000000001726f0 Call Trace: <TASK> groreceiveskb+0xee/0x230 mlxswsp1ptpgotpacket+0x61/0x140 [mlxswspectrum] mlxswcoreskbreceive+0xdf/0x1b0 [mlxswcore] mlxswpcinapipollcqrx+0x780/0x9d0 [mlxswpci] napipoll+0x31/0x1e0 napithreadedpollloop+0x16b/0x1c0 napithreadedpoll+0x71/0xa0 kthread+0xfb/0x260 retfromfork+0x22d/0x260 retfromforkasm+0x1a/0x30 </TASK> Kernel panic - not syncing: Fatal exception in interrupt

The machinery that leads to this kernel panic has not been changed between 6.18.48 and mainline.

This patch adds an ingress-delivery helper for the PTP packetfinish() path that calls netifreceiveskb() instead of napigroreceive(). netifreceiveskb(), unlike napigroreceive(), can be called from outside of the NAPI instance's poll context, which can occur at the call site for this path. RX stats accounting and the skb->dev assignment are still preserved; the only change is the delivery call itself.

This removes GR ---truncated---

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

vfio/pci: Check BAR resources before exporting a DMABUF

A DMABUF exports access to BAR resources and, although they are requested at startup time, we need to ensure they really were reserved before exporting. Otherwise, it's possible to access unreserved resources through the export.

Add a check to the DMABUF-creation path.

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

staging: rtl8723bs: fix mismatched free of HalData in rtwsdioif1init()

padapter->HalData is allocated via vzalloc(), but incorrectly freed using kfree() in the rtwsdioif1init() error path. Using kfree() to release this vmalloc-backed buffer can lead to memory corruption.

Use rtwhaldatadeinit() to pair the free correctly and free HalData with vfree().

The bug was first flagged by an experimental static analysis tool we are developing for kernel memory-management bugs. Manual inspection confirms that the issue is still present in current mainline.

An x8664 allyesconfig build showed no new warnings. As we do not have suitable RTL8723BS SDIO hardware to test with, no runtime testing was able to be performed.

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

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

KVM: x86: Fix shadow paging use-after-free due to unexpected GFN

The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). The flow is as follows:

- a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvmmmupage consisting of 512 4KB pages; the kvmmmupage is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous).

- the PDE mapping is changed from outside the guest.

- the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvmmmupage is zapped.

- the memslot that covers the first 2MB mapping is deleted, and the kvmmmupage for the now-invalid GPA is zapped. However, rmapremove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3.

- any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvmmmupage. This includes dirty logging or MMU notifier invalidations (e.g., from MADVDONTNEED).

The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvmmmupage must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but actually only happens in response to a guest write.

That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the "wrong" shadow page. However, that was only an imprecision until 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") came along.

Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.

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

eventpoll: fix epremove struct eventpoll / struct file UAF

epremove() (via epremovefile()) cleared file->fep under file->flock but then kept using @file inside the critical section (isfileepoll(), hlistdelrcu() through the head, spinunlock). A concurrent fput() taking the eventpollrelease() fastpath in that window observed the transient NULL, skipped eventpollreleasefile() and ran to fop->release / filefree().

For the epoll-watches-epoll case, fop->release is epeventpollrelease() -> epclearandput() -> epfree(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlisthead is exactly where epi->fllink.pprev points, so the subsequent hlistdelrcu()'s "pprev = next" scribbles into freed kmalloc-192 memory.

In addition, struct file is SLABTYPESAFEBYRCU, so the slot backing @file could be recycled by allocemptyfile() -- reinitializing flock and fep -- while epremove() is still nominally inside that lock. The upshot is an attacker-controllable kmemcachefree() against the wrong slab cache.

Pin @file via epifget() at the top of epremove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds fput() off and transitively keeps the watched struct eventpoll alive across the hlistdelrcu() and the flock use, closing both UAFs.

If the pin fails @file has already reached refcount zero and its fput() is in flight. Because we bailed before clearing fep, that path takes the eventpollrelease() slow path into eventpollreleasefile() and blocks on ep->mtx until the waiter side's epclearandput() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing eprefcountdecandtest() in epclearandput() cannot free the eventpoll out from under eventpollreleasefile(); the orphaned epi is then cleaned up there.

A successful pin also proves we are not racing eventpollreleasefile() on this epi, so drop the now-redundant re-check of epi->dying under flock. The cheap lockless READONCE(epi->dying) fast-path bailout stays.

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

ethtool: cmis: require exact CDB reply length

Malicious SFP module could respond with rpllen longer than what cmiscdbprocessreply() expected, leading to OOB writes. Malicious HW is a bit theoretical but some modules may just be buggy and/or the reads may occasionally get corrupted, so let's protect the kernel.

The existing check protects from short replies. We need to protect from long ones, too. All callers that pass a non-zero rplexplen cast the reply payload to a fixed-layout struct and read fields at fixed offsets, with no version negotiation or short-reply handling:

- cmiscdbvalidatepassword() - cmiscdbmodulefeaturesget() - cmisfwupdatefwmngfeaturesget()

so let's assume that responses longer than expected do not have to be handled gracefully here. Add a warning message to make the debug easier in case my understanding is wrong...

Note that pagedata->length (argument of kmalloc) comes from last arg to ethtoolcmispageinit() which is rplexplen.

Note2 that AIs also like to point out overflows in args->req.payload itself (which is a fixed-size 120 B buffer, on the stack), but callers should be reading structs defined by the standard, so protecting from requests for more data than max seem like defensive programming.

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

ALSA: pcm: oss: Fix setup list UAF on proc write error

sndpcmossprocwrite() links a newly allocated setup entry into the OSS setup list before duplicating the task name. If the task-name allocation fails, the error path frees the already linked entry and leaves setuplist pointing at freed memory.

A later OSS device open can then walk the stale list entry in sndpcmosslookforsetup() and dereference freed memory.

Allocate the task name and initialize the setup entry before publishing the entry on setuplist. Also fetch the initial proc read iterator only after taking setupmutex, so all setuplist traversal follows the same list lifetime rules.

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

accel/rocket: fix UAF via dangling GEM handle in createbo

rocketioctlcreatebo() inserts a GEM handle into the file's IDR via drmgemhandlecreate() early on, then performs several operations that can fail (sgt allocation, drmmm insert, iommumap). If any fail after the handle is live, the error path calls drmgemshmemobjectfree() which kfree's the object without removing the handle from the IDR.

This leaves a dangling handle pointing to freed slab memory. Any subsequent ioctl using that handle (PREPBO, FINIBO, SUBMIT) calls drmgemobjectlookup() and dereferences freed memory (UAF).

Fix by moving drmgemhandlecreate() to after all fallible operations succeed, matching the pattern used by panfrost, lima, and etnaviv.

Also fix drmmminsertnodegeneric() whose return value was silently overwritten by iommumapsgtable() on the next line. Add the missing error check.

[tomeu: Move handle creation to the very end]

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

Bluetooth: L2CAP: Fix possible crash on l2capecredconnrsp

If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2capchandel may invalidate the tmp cursor created by listforeachentrysafe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected.

Calling l2capchanclone directly may still lead to l2capchandel so instead schedule l2capchantimeout with delay 0 to close the channel asynchronously.

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

sctp: fix race between sctpwaitforconnect and peeloff

sctpwaitforconnect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTPSOCKOPTPEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctpwaitforconnect() returns success without noticing the migration — the caller then accesses the association under the wrong lock in sctpdatamsgfromuser().

Add the same sk != asoc->base.sk check that sctpwaitforsndbuf() already has, returning an error if the association was migrated while we slept.

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

vsock/virtio: bind uarg before filling zerocopy skb

virtiotransportsendpktinfo() allocates or reuses the zerocopy uarg before entering the send loop, but virtiotransportallocskb() still fills the skb before it inherits that uarg. When fixed-buffer vectored zerocopy hits MAXSKBFRAGS, iosgfromiter() may partially attach managed frags and return -EMSGSIZE. The rollback path call kfreeskb() to free an skb that carries SKBFLMANAGEDFRAGREFS but no uarg, so skbreleasedata() falls through to ordinary frag unref.

Pass the uarg into virtiotransportallocskb() and bind it immediately before virtiotransportfillskb(). This keeps control or no-payload skbs untouched while ensuring success and rollback share one lifetime rule.

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

wifi: iwlwifi: mei: pass correct argument to function

The first argument to iwlmeiwritecyclicbuf() should be the cldev but the qhead pointer is passed instead. Fix it.

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

KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation

Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01.

As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.

Bluetooth: l2cap: Add missing chan lock in l2capecredreconfrsp

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

zram: fix use-after-free in zrambvecwritepartial()

zramreadpage() picks the sync or async backing device read path based on whether the parent bio is NULL. zrambvecwritepartial() passes its parent bio down, so for ZRAMWB slots the read is dispatched asynchronously and zramreadpage() returns 0 while the bio is still in flight. The caller then runs memcpyfrombvec(), zramwritepage() and freepage() on the buffer, leaving the async read to write into a freed page.

zrambvecreadpartial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the writepartial counterpart was missed.

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

RDMA/mana: Validate rxhashkeylen

Sashiko points out that rxhashkeylen comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.

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

RDMA/vmwpvrdma: Fix double free on pvrdmaallocucontext() error path

Sashiko points out that pvrdmauarfree() is already called within pvrdmadeallocucontext(), so calling it before triggers a double free.

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

fs/smb/client: fix out-of-bounds read in cifssanitizeprepath

When cifssanitizeprepath is called with an empty string or a string containing only delimiters (e.g., "/"), the current logic attempts to check (cursor2 - 1) before cursor2 has advanced. This results in an out-of-bounds read.

This patch adds an early exit check after stripping prepended delimiters. If no path content remains, the function returns NULL.

The bug was identified via manual audit and verified using a standalone test case compiled with AddressSanitizer, which triggered a SEGV on affected inputs.

crypto: algifaead - Revert to operating out-of-place

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

RDMA/efa: Fix use of completion ctx after free

On admin queue completion handling, if the admin command completed with error we print data from the completion context. The issue is that we already freed the completion context in polling/interrupts handler which means we print data from context in an unknown state (it might be already used again). Change the admin submission flow so alloc/dealloc of the context will be symmetric and dealloc will be called after any potential use of the context.

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

nvme-pci: ensure we're polling a polled queue

A user can change the polled queue count at run time. There's a brief window during a reset where a hipri task may try to poll that queue before the block layer has updated the queue maps, which would race with the now interrupt driven queue and may cause double completions.

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

module: Fix kernel panic when a symbol stshndx is out of bounds

The module loader doesn't check for bounds of the ELF section index in simplifysymbols():

for (i = 1; i < symsec->shsize / sizeof(ElfSym); i++) { const char name = info->strtab + sym[i].stname;

switch (sym[i].stshndx) { case SHNCOMMON:

[...]

default: / Divert to percpu allocation if a percpu var. / if (sym[i].stshndx == info->index.pcpu) secbase = (unsigned long)modpercpu(mod); else / HERE --> / secbase = info->sechdrs[sym[i].stshndx].shaddr; sym[i].stvalue += secbase; break; } }

A symbol with an out-of-bounds stshndx value, for example 0xffff (known as SHNXINDEX or SHNHIRESERVE), may cause a kernel panic:

BUG: unable to handle page fault for address: ... RIP: 0010:simplifysymbols+0x2b2/0x480 ... Kernel panic - not syncing: Fatal exception

This can happen when module ELF is legitimately using SHNXINDEX or when it is corrupted.

Add a bounds check in simplifysymbols() to validate that stshndx is within the valid range before using it.

This issue was discovered due to a bug in llvm-objcopy, see relevant discussion for details [1].

[1] https://lore.kernel.org/linux-modules/20251224005752.201911-1-ihor.solodrai@linux.dev/

btrfs: set BTRFSROOTORPHANCLEANUP during subvol create

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

xfrm: prevent policyhthresh.work from racing with netns teardown

A XFRMMSGNEWSPDINFO request can queue the per-net work item policyhthresh.work onto the system workqueue.

The queued callback, xfrmhashrebuild(), retrieves the enclosing struct net via containerof(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrmhashrebuild() may then dereference stale memory.

xfrmpolicyfini() already flushes policyhashwork during teardown, but it does not synchronize policyhthresh.work.

Synchronize policyhthresh.work in xfrmpolicyfini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net.