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

xfrm: fix compat ALLOCSPI request use-after-free

xfrmstatenetlink() builds the ALLOCSPI response with dumponestate(), which already calls alloccompat() with the response skb and header.

xfrmallocuserspi() then calls alloccompat() again, but passes the original request skb and its header. For a compat request, the translator therefore interprets the 228-byte compat xfrmuserspiinfo as the 232-byte native layout and reads four bytes past the declared payload. It also publishes the translated child through the request's fraglist.

A multicast clone of the request shares skbsharedinfo and can observe that child. xfrmuserrcvmsg() frees it after the request handler returns, racing a compat receiver which may still be copying from it and resulting in a use-after-free.

Remove the redundant conversion. The response keeps its correct compat translation from dumponestate(), and no child is attached to the inbound request.

esp: downgrade zerocopy managed frags before mutating skb frags

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

RDMA/rxe: Fix integer overflow in mrcheckrange() leading to OOB access

mrcheckrange() validates that [iova, iova+length) falls within the registered MR range using wraparound-prone arithmetic:

if (iova < mr->ibmr.iova || iova + length > mr->ibmr.iova + mr->ibmr.length)

A remote peer can craft an RDMA-Write/Read RETH so that iova + length wraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the check. rxemriovatoindex() then computes a huge index (int idx, only guarded by WARNON) and rxemrcopyxarray() dereferences mr->pageinfo[huge], causing an out-of-bounds read/write and a kernel oops that is triggerable by an unauthenticated remote peer.

Rewrite the check in overflow-safe form; the first two clauses guarantee that the subsequent subtractions do not underflow:

if (iova < mr->ibmr.iova || length > mr->ibmr.length || iova - mr->ibmr.iova > mr->ibmr.length - length)

With the fix, mrcheckrange() returns -EINVAL for the crafted iova and the responder reports REMOTEACCESSERROR instead of triggering the OOB.

firmware: armscpi: reject DVFS OPP count above MAXDVFSOPPS

clk: scpi: bound-check DVFS index in scpidvfsrecalcrate

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

RDMA/rtrs-clt: Fix CQ pool leak when connect is interrupted

The client borrows shared CQ credits in the ADDRRESOLVED handler via ibcqpoolget(), before the peer is connected. createcm() can return -ERESTARTSYS from waiteventinterruptibletimeout() without destroying the CM ID. The initconns() and stop-and-destroy paths then call destroyconcqqp() while cq is still NULL (no PUT) and only afterwards rdmadestroyid().

CMA serializes the handler against rdmadestroyid() with handlermutex, but that does not order the GET against destroyconcqqp(). If ADDRRESOLVED has already passed the DESTROYING check, it can take conmutex, GET credits, and then lose the con to kfree. Device unregister later hits WARNON(cq->cqeused) in ibcqpoolcleanup().

Set a per-connection flag under conmutex before CQ/QP teardown so a racing ADDRRESOLVED cannot borrow credits after teardown has begun.

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

wifi: virtwifi: free skb when disconnected

When the simulated link is disconnected, virtwifistartxmit() returns NETXMITDROP without freeing the skb. devhardstartxmit() treats this return value as consumed, so every packet sent while disconnected leaks its skb.

Free the skb before returning the drop status.

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: check IP header size in cfg80211classify8021d()

A frame that looks like IP can be transmitted, but be too short, so the DS field is read incorrectly:

BUG: KMSAN: uninit-value in cfg80211classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 cfg80211classify8021d+0x99d/0x12b0 net/wireless/util.c:1027 ieee80211selectqueue+0x37a/0x9e0 net/mac80211/wme.c:180 ieee80211subifstartxmit+0x60f/0x1d90 net/mac80211/tx.c:4304 ieee80211subifstartxmit+0xa8/0x6d0 net/mac80211/tx.c:4538 ... packetsendmsg+0x9173/0xa2a0 net/packet/afpacket.c:3108

Use skbheaderpointer() like the MPLS case.

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

wifi: cfg80211: only group hidden BSSes with beacon entries

When a probe response for an unknown BSS comes in, cfg80211bssupdate() looks for an existing entry with the same BSSID and a hidden (zero-length or NUL-filled) SSID, and if it finds one it groups them, using the beacon IEs from the existing entry.

But that could find another entry without a beacon, if it was also from a probe response (with SSID), so there's a group without beacon elements.

If a beacon with a hidden SSID for that BSSID arrives later, cfg80211combinebsses() goes looking for the probe response entries that belong to it - i.e. entries with the same BSSID and channel that have no beacon IEs - and finds those two. They are already grouped with each other, so it hits its

WARNONONCE(bss->pub.hiddenbeaconbss) WARNONONCE(!listempty(&bss->hiddenlist))

which are there because an entry without beacon elements is not supposed to be part of a group yet.

Only combine entries when a beacon was already received, ones that are kept separate will be combined when a beacon arrives.

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: don't offload TC setup on APVLAN interfaces

APVLAN interfaces are purely virtual, so don't try to offload TC setup to drivers. We can't really use the AP interface either since we may not know it all the time, and it could technically even change.

Just reject the TC offload so things get done in software.

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: mac80211: add HE 6 GHz capability in the scan elems len

The HE 6 GHz Band Capability element is in the probe request for every band if 6 GHz is supported, so add the size to scanieslen.

Otherwise, building probe request elements can fail, triggering the WARNON in ieee80211startscan().

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

wifi: mac80211: mesh: release the channel if start fails

ieee80211joinmesh() acquires a channel context and then calls ieee80211startmesh(), which can fail. In that case, the chanctx isn't released then interface removal will attempt to unassign it after it's removed from the driver, hitting:

wlan0: Failed check-sdata-in-driver check, flags: 0x0 WARNING: net/mac80211/driver-ops.c:366 at drvunassignvifchanctx ieee80211assignlinkchanctx ieee80211linkreleasechannel ieee80211linkreleasechannel ieee80211teardownsdata unregisternetdevicemanynotify cfg80211unregisterwdev ieee80211removeinterfaces ieee80211unregisterhw mac80211hwsimdelradio hwsimexitnet

Correctly release the channel on start failures.

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

RDMA/siw: Bound fragmented header copies by the remaining length

siwgethdr() can receive an extended DDP/RDMAP header across more than one TCP callback. The first callback may receive most of the header, while the next one still limits the copy to hdrlen - MINDDPHDR instead of the number of missing bytes. This makes the destination move past the end of the header and overwrite the receive state, including fpdupartrcvd. A later callback can then use a negative fpdupartrcvd value as a copy offset, which creates an OOB write.

Use the number of header bytes already received when calculating the next copy length.

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

netfilter: nftnat: fully initialise newaddr in netmap setup

nftnatsetupnetmap() builds the mapped address in an on-stack union nfinetaddr. For an IPv4 mapping it writes only the 4-byte .ip member and the loop runs a single 32-bit iteration, but it then copies the whole 16-byte union into range->minaddr and range->maxaddr, so the upper 12 bytes reach nfnatsetupinfo() uninitialised.

KMSAN reports an uninit-value in nfnatsetupinfo() reached from nftnateval(). The IPv6 path fills all 16 bytes and is not affected.

Zero-initialise newaddr.

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.

drm: Fix drmpendingvblankevent leak in error path for outfenceptr

ALSA: bcd2000: Fix race between rawmidi and disconnect

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.

ALSA: hda: trace PCM open only after assigning a stream

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

ipv4: icmp: reject RTNUNREACHABLE input routes in icmproutelookup

When the forward output route cannot be used in icmproutelookup(), it enters the "reverse path" and calls iprouteinput() on fl4dec.daddr, the original packet's source address.

iprouteinput() only returns an error for truly invalid packets. For unreachable addresses it will succeed and return an input route whose dst.output is set to iprtbug(). The existing check only rejects RTNLOCAL routes, so the RTNUNREACHABLE route types can still be returned and later used for output, syzkaller triggering a WARNONONCE() in iprtbug() as bellow:

------------[ cut here ]------------ WARNING: net/ipv4/route.c:1273 at iprtbug+0x14/0x20 RIP: 0010:iprtbug+0x14/0x20 Call Trace: ippushpendingframes+0xfa/0x100 icmpsend+0x905/0xf10 ipoptionscompile+0xc0/0xd0 iprcvfinishcore+0x321/0xae0 iprcv+0x1de/0x260 netifreceiveskbonecore+0x11a/0x130 netifreceiveskb+0x7b/0x260 tungetuser+0x11bf/0x1c10 ------------[ cut here ]------------

Reject input route that is RTNUNREACHABLE to fix it. The net warning is only printed for RTNLOCAL, as RTNUNREACHABLE is not the result of a race condition.

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

net: bridge: mst: move switchdev call outside rcu

This is a follow-up of one of sashiko's pre-existing bug reports. brmstsetstate() calls switchdevportattrset() for nonzero MSTIs while holding rcureadlock() which invokes the blocking switchdev notifier chain and may sleep. Nonzero MSTI changes come from netlink with rtnl held. Move the switchdev call before entering the rcu section and assert that rtnl is held.

The call cannot be deferred because netlink needs its error and extack. Also DSA reads the old bridge MST state during the callback and checks it. A deferred callback will be late and will see the updated state.

dmaengine: mmppdma: fix wrong sg length in mmppdmaprepslavesg()

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

pppoatm: ensure a writable skb header and linear data

In pppoatmsend(), LLC encapsulation checks whether there is sufficient headroom for the 4-byte LLC header, but does not ensure that the skb header is writable.

Normal transmit packets passing through pppstartxmit() have their header unshared via skbcowhead(). However, packets can also reach pppoatmsend() via PPP channel bridging (PPPIOCBRIDGECHAN) without going through pppstartxmit().

Use skbcowhead() to ensure both sufficient headroom and a writable header before pushing the LLC header.

While at it: - Call pskbmaypull(skb, 1) before inspecting skb->data[0] to prevent out-of-bounds reads on zero-length or non-linear frames (e.g. from bridging). - Defer SCCOMPPROT protocol compression until after pppoatmmaysend() succeeds. This eliminates the temporary skb allocation on admission failure and completely removes the fragile "undo" heuristic at the nospace label, avoiding any risk of reading uninitialized headroom or performing an unbalanced skbpush().

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:

net: ethernet: cortina: Ack RX overrun interrupt correctly

The RX overrun interrupt is reported in interrupt status register 4, but gmacirq() acknowledges it using the RX descriptor error bit from status register 0. For GMAC0 this writes the GMAC1 overrun bit, while for GMAC1 the shift leaves no bit in the 32-bit register.

Acknowledge the same per-port RX overrun bit that was detected.

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

net: mvpp2: prevent buffer overflow in pagepool allocation

The per‑processor buffering scheme is supported only if the number of pools (nrxqs  2) does not exceed MVPP2BMMAXPOOLS (8). This is already checked in mvpp2probe() during the initial activation of percpupools.

However, mvpp2changemtu() may later call mvpp2bmswitchbuffers(priv, true) without this check, which can lead to an out-of-bounds access in the priv->pagepool array in mvpp2bminit(). The array is sized to hold MVPP2PORTMAXRXQ entries, and mvpp2getnrxqs() may return exactly that value. The per-CPU scheme then doubles it to nrxqs 2, exceeding the array bounds.

Check that the hardware version is MVPP22 or newer and that the number of pools (nrxqs 2) does not exceed MVPP2BMMAXPOOLS before switching to per-CPU mode.

Found by Linux Verification Center (linuxtesting.org) with SVACE.