In epfree of eventpoll.c, there is a possible use-after-free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

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

xfrm: add missing rcureadlock(), skbdstforce() and devhold() for xfrmtransreinject()

syzbot reported a suspicious RCU usage warning in ip6pktdrop():

WARNING: suspicious RCU usage in ip6pktdrop include/net/addrconf.h:389 suspicious rcudereferencecheck() usage!

Call Trace: in6devgetsafely include/net/addrconf.h:389 [inline] ip6pktdrop+0x596/0x610 net/ipv6/route.c:4620 ip6pktdiscard+0x1c/0x30 net/ipv6/route.c:4651 xfrmtransreinject+0x324/0x630 net/xfrm/xfrminput.c:806 processonework kernel/workqueue.c:3322 [inline] processscheduledworks+0xa8e/0x14e0 kernel/workqueue.c:3405 workerthread+0xa47/0xfb0 kernel/workqueue.c:3486

When commit 4f4920669d21 ("xfrm: Reinject transport-mode packets through workqueue") converted xfrmtransreinject from a tasklet to a workqueue, the reinjection loop ceased running in softirq context. Workqueue workers run in process context where localbhdisable() does not enter an RCU read-side critical section under CONFIGPREEMPTRCU.

Because finish callbacks (such as ip6rcvfinish) expect to run under an RCU read lock (performing route lookups, l3mdev lookups, and accessing RCU-protected data structures), invoking them in workqueue context without rcureadlock() triggers RCU lockdep warnings.

Furthermore, packets queued to the workqueue via xfrmtransqueuenet() may carry non-refcounted (noref) dst entries (e.g. from iprouteinputnoref). Additionally, on netdevice unregistration, dstdevput() replaces dst->dev with blackholenetdev, so dst entries do not keep skb->dev alive while queued in the workqueue.

Fix these issues by: 1. Calling skbdstforce(skb) in xfrmtransqueuenet() while still in the caller's RCU section to ensure dst is reference-counted before queuing. 2. Holding a reference on skb->dev via devhold()/devput() across workqueue deferral so skb->dev remains valid during finish() callback processing. 3. Acquiring rcureadlock() around the finish callback invocation loop in xfrmtransreinject().

esp: downgrade zerocopy managed frags before mutating skb frags

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

RDMA/siw: Clear association under lock if siwqpmodify fails in siwaccept

We need to clear cep before release statelock as siwqpllpclose and siwqpmodify->siwqpllpclose did.

Otherwise if siwqpmodify() fails in siwaccept(), the QP's statelock is released before the error path cleanup. A concurrent ibvmodifyqp() transitioning the QP to ERROR can race in this window:

siwaccept() ibvmodifyqp(ERROR) ---------------------- ---------------------- siwqpmodify() fails upwrite(&qp->statelock) downwrite(&qp->statelock) nextstatefromidle(): if (qp->cep) siwcepput(qp->cep) <- frees cep qp->cep = NULL goto error cep->qp = NULL <- UAF

Clear qp->cep and drop the association reference taken by siwcepget(), all under the write lock held from the initial downwrite(&qp->statelock). Thread B therefore sees qp->cep == NULL, skips its own put, and cannot free the cep before siwaccept() is done with it.

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

RDMA/rxe: validate access flags before swapping the MR's PD

rxereregusermr() reassigns mr->ibmr.pd first and only then validates the IBMRREREGACCESS argument:

if (flags & IBMRREREGPD) { rxeput(oldpd); rxeget(pd); mr->ibmr.pd = ibpd; }

if (flags & IBMRREREGACCESS) { if (access & ~RXEACCESSSUPPORTEDMR) return ERRPTR(-EOPNOTSUPP); mr->access = access; }

Both flags pass the entry check because RXEMRREREGSUPPORTED is IBMRREREGPD | IBMRREREGACCESS, so a caller can reach the access check with mr->ibmr.pd already reassigned.

mr->ibmr.pd is owned by the core, which adjusts pd->usecnt only on the success path: ibuverbsreregmr() jumps to putnewuobj on a driver error without undoing the reassignment, so mr->pd == newpd while the usecnts still charge the MR to origpd. ibderegmruser() then decrements newpd, whose count can reach zero while a memory window still references it; uverbsfreepd() frees the PD on that count alone and rxemwcleanup() writes to freed memory:

BUG: KASAN: slab-use-after-free in rxeput+0x31/0xa0 Write of size 4 at addr ffff8881301dd690 by task rxepoc/591 rxeput+0x31/0xa0 rxemwcleanup+0x42/0x200 rxecleanup+0x115/0x370 rxedeallocmw+0x4c/0x80 Allocated by task 591: ibuverbsallocpd+0x258/0x540 Freed by task 591: ibdeallocpduser+0x174/0x210 uverbsfreepd+0x8d/0xc0 ibuverbsdeallocpd+0x18e/0x1d0

Validate the access flags before mutating any state so the callback either applies every requested change or none.

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

xfrm: hold netdevice reference under RCU in bundle creation

xfrmbundlecreate() and xfrmcreatedummybundle() read dst->dev into a local pointer without taking a device reference, then pass it to xfrmfilldst(). A concurrent RTMDELLINK replaces dst->dev via dstdevput() and frees the old netdevice, causing a use-after-free when xfrm6filldst() later dereferences the stale dev pointer.

BUG: KASAN: slab-use-after-free in xfrm6filldst+0x82c/0x860 (net/ipv6/xfrm6policy.c:86 netdevhold()) Read of size 8 at addr ffff8880142fe588 by task exploit/153 Call Trace: xfrm6filldst+0x82c/0x860 xfrmresolveandcreatebundle+0x21d4/0x2bd0 xfrmlookupwithifid+0x485/0x1640 ip6dstlookupflow+0x19b/0x1e0 udpv6sendmsg+0x1443/0x2dd0

Fix this by reading dst->dev via dstdevrcu() and keeping the RCU read-side critical section active until xfrmfilldst() has taken the required device references.

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

RDMA/rxe: Restore HMMPFNWRITE check in ODP write paths

Commit 0b261d7c1cd3 ("RDMA/rxe: Break endless pagefault loop for RO pages") dropped the access permission test from rxecheckpagefault() and left only HMMPFNVALID. A page faulted in read-only, for example a page-cache folio behind a PROTREAD file mapping, then satisfies the check and ODP write operations (RDMA WRITE, RDMA READ response, SEND payload, atomics) modify it through kmap without ever breaking CoW.

An unprivileged user can register an ODP MR over such a mapping and have incoming RDMA traffic overwrite the page cache of a file it only holds ORDONLY, including /etc/passwd or setuid binaries. This is the same primitive class as Dirty COW and CVE-2022-2590.

mlx5 has the missing invariant: its ODP path sets the device write bit only for pfns that carry HMMPFNWRITE. Restore it in rxe by requiring HMMPFNWRITE in rxecheckpagefault() for every operation except RXEPAGEFAULTRDONLY. A write to a non-writable VMA now fails the one fault attempt with -EPERM from hmmvmafault() instead of re-faulting forever. For a writable VMA the fault breaks CoW and the write lands in the private page.

Keep pmem flushes on the read-only check. archwbcachepmem() never modifies memory, and the FLUSH access bits do not make the umem writable, so classifying flushes as writes would make every flush against a flush-only MR fail.

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

RDMA/rxe: insert mcg into mcgtree only after rxemcastadd() succeeds

rxegetmcg() publishes a newly allocated multicast group in rxe->mcgtree before programming the backing Ethernet multicast address with rxemcastadd(), which runs outside mcglock. A local userspace RDMA client reaches this path with ATTACHMCAST on a UD QP; if rxemcastadd() then returns an error (for example -ENODEV when the backing netdev has been removed, or a propagated devmcadd() error), the unwind frees the published group without removing it from the tree. A later lookup of the same MGID dereferences the freed struct rxemcg from rxelookupmcg().

Fix this by keeping the new mcg private until rxemcastadd() succeeds. Split the tree publication into rxepublishmcg(), call rxemcastadd() before taking the tree reference, and free the still-private mcg on failure. Because the group is never visible in mcgtree until the multicast address is programmed, no concurrent caller can look it up or attach a QP to a group that is about to be torn down, so the error path needs no conditional unwind. If another caller publishes the same MGID while the address is being programmed, the post-add re-check under mcglock finds the winner; this caller then drops its private object and balances its own rxemcastadd() with rxemcastdel() before returning the winner.

Reproduced by forcing the rxemcastadd() error return under KASAN: without the change the next attach to the same MGID reports a slab-use-after-free in rxelookupmcg(); with it the forced failure returns cleanly. A no-injection attach/detach regression, including a two-QP shared join/leave and re-attach, stays KASAN- and leak-clean.

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

RDMA/core: Reject unregistering netdevs in ibgetethspeed

ibdevicegetnetdev() intentionally returns a referenced netdevice even when it is unregistering, so matching and cleanup callers can still find the association. The reference keeps struct netdevice allocated, but does not guarantee that the device remains operational.

ibgetethspeed() uses the returned device operationally by invoking its ethtool callback. Although that call is made under RTNL, the function does not verify the registration state first. An asynchronous RDMA port query can therefore call into a netdev after NETDEVUNREGISTER and ndouninit have completed.

Check for NETREGREGISTERED while holding RTNL and return -ENODEV for a device which is being unregistered. Keeping RTNL across the check and the ethtool operation prevents unregister from starting between them.

Keep the speed fallback and warning under RTNL as well, so the warning can safely read netdev->name. Drop the netdev reference before releasing RTNL once all accesses to the device are complete.

IB/isert: wait for deferred control PDU completions before releasing the connection

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

wifi: libipw: reject too-short beacon and probe responses

libipwprocessproberesponse() and the libipwnetworkinit() call it makes assume the frame contains the full 36-byte beacon and probe response prefix, but the ipw2100 and ipw2200 receive paths only establish that a management frame carries the generic 24-byte three-address header.

libipwnetworkinit() then computes the information element length as

stats->len - sizeof(beacon)

stats->len is a u16 and sizeof() has type sizet, so the subtraction is evaluated as sizet and wraps instead of going negative. Truncating that to the u16 length parameter of libipwparseinfoparam() yields 65524 for a 24-byte beacon, and the parser then walks the receive buffer as if it held almost 64 KiB of information elements, reading past the allocation.

Reject the frame before any fixed field is touched.

Found by an AI-assisted review of length arithmetic in management frame parsers. Verified with a KUnit case under Generic KASAN on arm64 under QEMU; I do not have the hardware, so it is not tested on a real device.

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

wifi: libipw: reject too-short association responses

libipwhandleassocresp() reads the capability, status and aid fields of the 30-byte association response prefix and then computes the information element length as

stats->len - sizeof(frame)

stats->len is a u16 and sizeof() has type sizet, so the subtraction is evaluated as sizet and wraps instead of going negative. Truncating that to the u16 length parameter of libipwparseinfoparam() turns a frame shorter than the fixed fields into a length near 64 KiB, and the parser then reads past the receive buffer.

Both the ipw2100 and ipw2200 management receive paths reach this function having established only that the frame carries the generic 24-byte three-address header.

Reject the frame before any fixed field is touched.

Found by an AI-assisted review of length arithmetic in management frame parsers. Verified with a KUnit case under Generic KASAN on arm64 under QEMU; I do not have the hardware, so it is not tested on a real device.

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

wifi: cfg80211: don't free driver-owned scan requests

When an interface goes down while a scan is running, cfg80211 completes the scan towards userspace and frees the scan request. However, the driver can be convinced that it owns the request, since the cancellation is (intended to be) asynchronous.

The WARNON() in the netdev notifier was meant to catch this, but it's not actually avoidable, so it triggers and we get a UAF in scandone().

There doesn't seem to be a great way around it, so just track that the driver is still convinced it owns the request, and then just free it on completion if it was already cancelled. Also remove the warnings since they can trigger in the intended architecture.

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

wifi: cfg80211: don't filter by BSS type when removing stale entries

When an assoc AP switches to a channel that already has a BSS entry, cfg80211updateassocbssentry() removes that entry before rehashing the real one, since the two would otherwise collide in the BSS rbtree.

The lookup for that entry also required it to match the connection's BSS type, so an entry advertising e.g. the IBSS capability bit was left in place, and the following cfg80211rehashbss() then ran into it:

WARNON(!cmp)

Changing the type shouldn't really happen, but can be triggered by a rogue AP/device, so drop the check and remove any entries matching the comparison.

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

wifi: mac80211: unlist vifs when their netdev is unregistered

mac80211 only removes vifs from the local->interfaces list when an interface is removed via ieee80211ifremove(), before it unregisters the netdev. However, it's possible for a netdev to be unregistered without going through that: When the netns that holds the wiphy is destroyed, the wiphy is supposed to move to the initns, but that can run into allocation failures.

Then, mac80211 has an interface listed that doesn't exist, and will eventually hit

BUG: failure at net/wireless/core.h:141/wiphytordev()! ... cfg80211unregisterwdev+0x24/0x36a [cfg80211] cfg80211unregisterwdev+0x15/0x1d [cfg80211] ieee80211removeinterfaces+0x1ff/0x257 [mac80211] ieee80211unregisterhw+0x73/0x1d1 [mac80211] mac80211hwsimdelradio+0x114/0x166 [mac80211hwsim]

Remove the interface from the list in ->ndouninit if it's still around to avoid this.

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

wifi: cfg80211: get the wiphy out of a dying network namespace

When a network namespace is destroyed, cfg80211pernetexit() moves any wiphy back to the initial namespace, and just warns if that fails. But moving an interface can fail (due to allocation failures), and then the wiphy is left behind with a garbage netns pointer:

Kernel mode fault at addr 0x30 genlmsgmulticastnetns.constprop.0+0x46/0xcf [cfg80211] nl80211notifywiphy+0xcd/0xe8 [cfg80211] wiphyunregister+0x169/0x3fc [cfg80211]

Note that commit debac3a20dec ("net: Remove conflicting altnames for dying netns in devchangenetnamespace().") fixed another path that could reach it without allocation failures.

Remove interfaces that cannot be moved instead of failing the switch, so that the wiphy always ends up in the initial namespace. In this case the netdev core will unregister the interfaces anyway.

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

dmaengine: pxa: fix double counting of the hw descriptors

pxadallocdesc() was converted from

kzalloc(structsize(swdesc, hwdesc, nbhwdesc), GFPNOWAIT)

to kzallocflex(), which sets the countedby() counter swdesc->nbdesc itself - but only where the compiler has builtincountedbyref(), so from gcc 15.1 or clang 22.1 on. The loop below it still increments nbdesc, which makes it come out doubled there and correct elsewhere.

nbdesc is what pxadfreedesc() iterates over and what setupdaterdesc() indexes from, so set it explicitly and drop the increment. The error path has to lower it to the number of descriptors allocated so far, otherwise pxadfreedesc() would free entries that were never allocated.

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

netfilter: flowtable: hold reference on ct until flow is released

nfctput() releases the ct->ext area inmediately, the rcu typesafe semantics also allow to refer to the wrong conntrack from the flowtable datapath. Hold reference on ct until flow is released after rcu grace period.

Add rcubarrier() on module exit path, to ensure pending flow entries are release before module goes away.

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

smb: client: validate absolute native symlink targets before NT fixups

With symlinkroot unset, an absolute target is copied without conversion to an NT drive path. Later code still assumes an NT prefix is present when modifying the target and calculating the print name length.

For "/ab", this causes two failures: sym[5] and path[5] are written past their allocations, and plen -= 2 poff subtracts an assumed 8-byte prefix from a 6-byte UTF-16 target, wrapping u16 plen to 65534. That underflow causes another overflow: memcpy() copies 65534 bytes into a 24-byte buffer. A user with write access to a mounted share can trigger these bugs with default settings.

Validate the NT drive prefix, including an ASCII drive letter, before accessing fixed offsets or subtracting the prefix length.

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

ntfs: protect runlist updates with the runlist lock

ntfsnonresidentattrshrink() calls runlist helpers that require the runlist write lock, but did not hold it while freeing clusters and truncating the runlist. Serialize those operations and the resident conversion with the runlist lock.

ntfsattrmapcluster() can merge a newly allocated run before updating mapping pairs. If the update fails, free the clusters and restore both the in-memory runlist and on-disk mapping pairs from a saved runlist. Mark the volume in error if either rollback step fails.

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

wifi: virtwifi: don't transfer operstate before register

virtwifinewlink() calls netifstackedtransferoperstate() before registernetdevice(). If the lower device is dormant, that queues the new netdev on lweventlist while it is still uninitialized. If registration fails after that, for example because of an invalid name such as "bad/name", freenetdev() immediately frees the object. A later linkwatchfireevent() then use-after-frees the list entry.

Move the transfer to after netdevupperdevlink(), as macvlan and ipvlan already do.

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

net: dsa: mxl862xx: disable the stats poll on teardown

mxl862xxsetup() arms the stats poll before mxl862xxsetupmdio(), and nothing stops it until dsaregisterswitch() has returned an error to mxl862xxprobe(). DSA frees the dsaport list before it returns, so a poll that fires once .setup or a later step of dsatreesetup() has failed walks freed ports. On shutdown the user ports stay registered, and the WORKSTOPPED flag test in mxl862xxgetstats64() is not atomic with the cancel in mxl862xxshutdown(), so a re-arm that read the flag before it was set queues the poll after canceldelayedworksync() has returned.

Arm the poll once .setup has succeeded and stop it from a .teardown op, which DSA calls on unregister and after a failed registration, in both cases before it frees the ports. Use disabledelayedworksync() there and in shutdown(): it drains a running poll as the cancel did and turns every later attempt to queue the work into a no-op, so the re-arm cannot bring the poll back. remove() and the probe error path only set WORKSTOPPED, which crcerrwork tests before it walks the ports.

Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup

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

KVM: PPC: Book3S HV: fix use-after-free in kvmhvemulatetlbiealllpid()

kvmhvemulatetlbiealllpid() iterates the nested-guest IDR and drops mmulock before calling kvmhvemulatetlbielpid(), but does not hold a reference on the kvmnestedguest pointer obtained from the IDR. A concurrent vCPU issuing a single-LPID tlbie (is=2, ric=2) can race through kvmhvflushnested() -> kvmhvremovenested() -> idrremove / --refcnt -> kvmhvreleasenested() -> kfree(gp) in that window, leaving the iterating vCPU with a dangling pointer. The subsequent mutexlock(&gp->tlblock) and accesses to gp->shadowpgtable, gp->shadowlpid and gp->l1host all touch freed memory. The free path is fully L1-controlled.

Fix this by incrementing gp->refcnt inside the loop before dropping mmulock, mirroring what kvmhvgetnested() does, and releasing the reference with kvmhvputnested() after the per-guest work completes. This is the same get/put discipline already used at every other call site that drops mmulock while holding a nested-guest pointer.

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

powerpc/iommu: Fix the overflow validation in iommutcecheckioba

The commit b1af23d836f8 ("KVM: PPC: iommu: Unify TCE checking") unified IOBA parameter checking across KVM and VFIO into iommutcecheckioba(). While doing so, the passed in argument npages is ignored and constant value '1' is used leaving out a possible overflow as the callers can legitimately be using npages > 1 for HSTUFFTCE or HPUTTCEINDIRECT cases.

Fix this by accounting for 'npages', checking for arithmetic overflow, and verifying that the entire requested range (ioba - offset + npages) does not exceed the table capacity 'size'.

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

futex: Also allocate private hash on vfork()

As Jann demonstrated, it is entirely feasible to access the mm through vfork(). Therefore we need to allocate a private hash on vfork() as well as any other CLONEVM user.

Specifically, it must be avoided to have (private) futex waiters before allocating the private hash.

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

net: lock the socket in sockgettstamp()

sk->skflags must only be changed while holding the socket lock, because socksetflag() and sockresetflag() use non atomic operations (setbit() and clearbit()).

sockgettstamp() is one of the last places where a bit of sk->skflags is changed from a syscall without owning the socket lock, through sockenabletimestamp(sk, SOCKTIMESTAMP).

sksetmemalloc() and skclearmemalloc() also change sk->skflags without the socket lock, but their callers (nbd, iscsitcp, nvme-tcp, sunrpc, wireguard) need a careful audit, this will be addressed in a separate patch.

Jungwoo Lee and Wongi Lee reported an UDP socket use-after-free caused by this bug: a SIOCGSTAMPNSNEW ioctl racing with bind() can cancel the SOCKRCUFREE bit that udplibgetport() just set, because both threads perform a read-modify-write on the same word.

CPU 0 (bind) CPU 1 (SIOCGSTAMPNSNEW) -------------------------------- ---------------------------- read skflags = F read skflags = F compute F | BIT(SOCKRCUFREE) compute F | BIT(SOCKTIMESTAMP) store F | BIT(SOCKRCUFREE) skaddnodercu(sk, ...) store F | BIT(SOCKTIMESTAMP)

After the lost update, SOCKRCUFREE is clear while the socket is visible to lockless UDP receive lookups. skdestruct() then frees the socket immediately instead of waiting for a RCU grace period, while the receive path still holds a reference-less pointer to it:

BUG: KASAN: slab-use-after-free in ipv4pktinfoprepare+0x30/0x410 Read of size 8 at addr ffff888008806610 by task exploit/207 CPU: 0 UID: 1000 PID: 207 Comm: exploit Not tainted 6.12.95+ #1 ipv4pktinfoprepare+0x30/0x410 udpqueuercvoneskb+0x51c/0x1180 udpunicastrcvskb+0x109/0x350 ipprotocoldeliverrcu+0x14b/0x310 iplocaldeliverfinish+0x29d/0x390 iplocaldeliver+0x24d/0x2a0

Only grab the socket lock when SOCKTIMESTAMP has to be set, to keep the common case lockless.

cifs: Fix server use-after-free in cifschanskipordisable()

exec: Cleanup POSIX timers right after dethread()

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

posix-cpu-timers: Prevent freeing a timer which is queued on the expiry list

Kijo analyzed another race in the POSIX CPU timer code:

Commit bf635681c906 converted cputimer::firing from a tristate value to a boolean. This lost the distinction between "not owned by the firing list" and "still owned, but delivery was canceled". The resulting race is:

expiry handler timersettime() timerdelete() -------------- --------------- -------------- collect timer onto private firing list firing = true observes firing = true firing = false return TIMERRETRY wait for handler observes firing = false finish deletion unhash and free timer resume list traversal read freed elist.next -> UAF

The firing bit is clearly the wrong indicator since that commit.

Check whether the timer is queued on the expiry list or not instead. If it is queued clear the firing bit to prevent signal delivery as before and return TIMERRETRY so the caller unlocks the timer which allows the expiry code to make progress and remove it from the list.