OESA-2026-3703

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ASoC: qcom: Fix sc7280 lpass potential buffer overflow

Case values introduced in commit 5f78e1fb7a3e ("ASoC: qcom: Add driver support for audioreach solution") cause out of bounds access in arrays of sc7280 driver data (e.g. in case of RXCODECDMARX0 in sc7280sndhw_params()).

Redefine LPASSMAXPORTS to consider the maximum possible port id for q6dsp as sc7280 driver utilizes some of those values.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37979)

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

net: usb: asix_devices: Fix PHY address mask in MDIO bus initialization

Syzbot reported shift-out-of-bounds exception on MDIO bus initialization.

The PHY address should be masked to 5 bits (0-31). Without this mask, invalid PHY addresses could be used, potentially causing issues with MDIO bus operations.

Fix this by masking the PHY address with 0x1f (31 decimal) to ensure it stays within the valid range.(CVE-2025-38736)

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

crypto: afalg - Fix page reassignment overflow in afalgpulltsgl

When page reassignment was added to afalgpull_tsgl the original loop wasn't updated so it may try to reassign one more page than necessary.

Add the check to the reassignment so that this does not happen.

Also update the comment which still refers to the obsolete offset argument.(CVE-2026-43078)

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

crypto: algif_aead - snapshot IV for async AEAD requests

AF_ALG AEAD AIO requests currently use the socket-wide IV buffer during request processing. For async requests, later socket activity can update that shared state before the original request has fully completed, which can lead to inconsistent IV handling.

Snapshot the IV into per-request storage when preparing the AEAD request, so in-flight operations no longer depend on mutable socket state.(CVE-2026-46028)

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

xfrm: esp: restore combined single-frag length gate

The ESP out-of-place fast path appends the trailer in espoutputhead() before espoutputtail() allocates the destination page frag. The head-side gate currently checks skb->datalen and tailen separately, but the tail code allocates a single destination frag from the combined post-trailer skb->datalen.

Reject the page-frag fast path when the combined aligned length exceeds a page. Otherwise skbpagefragrefill() may fall back to a single page while the destination sg still spans the combined skb->datalen.

Restore this combined-length page gate for both IPv4 and IPv6.(CVE-2026-63912)

In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation. __ipvsgetoutrt() calls skbensurewritable() which may reallocate skb->head, causing the previously obtained IP header pointer to become a dangling pointer, leading to a use-after-free vulnerability.(CVE-2026-68476)

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

ipvs: fix more places with wrong ipv6 transport offsets

Sashiko reports for more incorrect IPv6 transport offsets.

The app code for TCP was assuming IPv4 network header even after the ipvsh argument was provided. This can cause problems with apps over IPv6. As for the only official app in the kernel tree (FTP) this problem is harmless because we use Netfilter to mangle the FTP ports and we do not adjust the TCP seq numbers.

Also, provide correct offset of the ICMPV6 header in ipvsouticmpv6() for correct checksum checks when the IPv6 packet has extension headers.(CVE-2026-68477)

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

ipvs: use parsed transport offset in SCTP state lookup

setsctpstate() reads the SCTP chunk header again in order to drive the IPVS SCTP state table. For IPv6 it computes the offset with sizeof(struct ipv6hdr), while the surrounding IPVS code uses iph.len from ipvsfilliphskb(), where ipv6findhdr() has already skipped extension headers and found the real transport header.

This makes the state machine read from the wrong offset for IPv6 SCTP packets that carry extension headers. For example, an INIT packet with an 8-byte destination options header can be scheduled correctly by sctpconnschedule(), but setsctpstate() reads the first byte of the SCTP verification tag as a DATA chunk type. The connection then moves from NONE to ESTABLISHED instead of INIT1, gets the longer established timeout, and updates the active/inactive destination counters incorrectly. This happens even though the SCTP handshake has not completed.

Use the parsed transport offset passed down from ipvsset_state() for the SCTP chunk-header lookup. For IPv4 and IPv6 packets without extension headers this preserves the existing offset.(CVE-2026-72021)

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

ieee802154: admin-gate legacy LLSEC dump operations

In net/ieee802154/netlink.c, the legacy IEEE802154NL family ops table builds the LLSEC dump entries (LLSECLISTKEY, LLSECLISTDEV, LLSECLISTDEVKEY, LLSECLISTSECLEVEL) with IEEE802154DUMP() which sets no .flags, so generic netlink runs them ungated. The modern nl802154 family admin-gates the equivalent reads via NL802154CMDGETSECKEY and friends with .flags = GENLADMINPERM.

Any local uid that can open AFNETLINK / NETLINKGENERIC can resolve the "802.15.4 MAC" family and dump LLSECLISTKEY on any wpan netdev that has an LLSEC key installed; the dump handler writes the raw 16-byte AES-128 key bytes (IEEE802154ATTRLLSECKEYBYTES, copied verbatim from struct ieee802154llseckey.key) into the reply. Recovering the AES key compromises 802.15.4 LLSEC link confidentiality and authenticity, since LLSEC uses CCM* and the same key authenticates and encrypts frames.

Impact: any local uid with no capabilities can read the raw 16-byte AES-128 LLSEC key from the kernel keytable on any wpan netdev that has an administrator-installed LLSEC key, by issuing an LLSECLISTKEY dump on the legacy IEEE802154_NL generic-netlink family.

Introduce IEEE802154DUMPPRIV() mirroring IEEE802154DUMP() but setting .flags = GENLADMINPERM, and use it for the four LLSEC dump entries. LISTPHY and LISTIFACE retain IEEE802154DUMP() because the modern nl802154 family exposes their equivalents to unprivileged readers by design (NL802154CMDGETWPANPHY and NL802154CMDGET_INTERFACE carry "can be retrieved by unprivileged users" annotations).(CVE-2026-72049)

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

net: ip6gre: require CAPNET_ADMIN in the device netns for changelink

ip6grechangelink() and ip6erspanchangelink() operate on at most two netns, devnet(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAPNETADMIN only against devnet(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate both ops on rtnldevlinknetcapable() at their top, before any attribute is parsed.(CVE-2026-72052)

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

net: ipip: require CAPNETADMIN in the device netns for changelink

ipipchangelink() operates on at most two netns, devnet(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAPNETADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate ipipchangelink() on rtnldevlinknet_capable() at its top, before any attribute is parsed.(CVE-2026-72053)

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

net: ipvti: require CAPNET_ADMIN in the device netns for changelink

vtichangelink() operates on at most two netns, devnet(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAPNETADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate vtichangelink() on rtnldevlinknet_capable() at its top, before any attribute is parsed.(CVE-2026-72054)

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

net: sit: require CAPNETADMIN in the device netns for changelink

ipip6changelink() operates on at most two netns, devnet(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAPNETADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.

Gate ipip6changelink() on rtnldevlinknet_capable() at its top, before any attribute is parsed. sit was the one tunnel type not covered by the recent series that added this check to the other changelink() handlers.(CVE-2026-72061)

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

net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete

When an offloaded MACsec RX SC is deleted, macsecdelrxscctx() freed the per-SC metadatadst with metadatadstfree(), which kfree()s the object unconditionally and ignores the dst reference count. The RX datapath in mlx5emacsecoffloadhandlerxskb() looks up the SC under rcureadlock() via xaload(), takes a reference with dsthold() and attaches the dst to the skb with skbdstset(). A reader that already obtained the rxsc pointer can race with the delete path and operate on freed memory.

Fix the owner side by dropping the reference with dstrelease() instead of freeing unconditionally, and convert the RX datapath to dsthold_safe() so a reader racing the SC delete cannot attach a dst whose last reference was just dropped; only attach it when a reference was actually taken.

mlx5emacsecaddrxsc() also published scxarrayelement via xaalloc() before rxsc->mddst was allocated and initialised, so a datapath reader that looked the SC up by fsid could observe rxsc with mddst still NULL or, on weakly-ordered architectures, a non-NULL mddst pointer whose contents were not yet visible. NULL-check the xaload() result and mddst on the datapath, and reorder addrxsc() so the xaalloc() publish happens only after mddst is fully initialised; the xarray RCU publish then pairs with the rcureadlock()/xaload() in the datapath.

Note: macsecdelrxscctx() also kfree()s rxsc->scxarrayelement without an RCU grace period while the same datapath reads it under rcureadlock(); that is a separate pre-existing issue left to a follow-up patch.

Found by 0sec automated security-research tooling (https://0sec.ai).(CVE-2026-72072)

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

nvmet-rdma: handle inline data with a nonzero offset

nvmetrdmauseinlinesg() maps the host-controlled inline data offset into the per-command inline scatterlist. The bounds check admits any offset with off + len <= inlinedatasize, but the mapping still assumes the data begins in the first inline page:

sg->offset = off;
sg->length = min_t(int, len, PAGE_SIZE - off);

When a port is configured with inlinedatasize > PAGESIZE (settable up to max(SZ16K, PAGESIZE)), an offset in (PAGESIZE, inlinedatasize] makes "PAGESIZE - off" underflow, so sg->length is set to ~4 GiB and the block backend reads far past the first inline page. numpages(len) also ignores the offset, so an in-bounds offset whose [off, off+len) span crosses a page boundary under-counts the scatterlist.

Map the offset properly: split it into a page index and an in-page offset, start the scatterlist at that page, and size the page count from pageoff + len. Because the request scatterlist may now start at inlinesg[pageidx] rather than inlinesg[0], generalize the inline-SGL identity test in nvmetrdmareleasersp() to a range test; otherwise the persistent inline scatterlist is mistaken for an allocated one and nvmetreqfreesgls() frees an inline page (and warns in freelargekmalloc()).(CVE-2026-72129)

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

tpm: Make the TPM character devices non-seekable

The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODEPREAD and FMODEPWRITE enabled.

After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as *off to tpmcommonread(). The transfer length is bounded by responselength, but the offset is used unchecked when forming databuffer + *off. A sufficiently large offset therefore causes an out-of-bounds heap read through copytouser() and, if the copy succeeds, an out-of-bounds zero-write through the following memset().

Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of databuffer, while pwrite() does not update file->fpos and can leave the sequential read cursor stale.

Call nonseekableopen() from both open handlers. This removes FMODEPREAD and FMODEPWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential fpos cursor, leaving the response state machine unchanged.

Tested on Linux 6.12 with KASAN and a swtpm TPM2 device:

• sequential partial reads returned the complete response
• pread() and preadv() with offset 0x1400 returned -ESPIPE
• pwrite() and pwritev() with offset zero returned -ESPIPE
• the pending response remained intact after the rejected operations
• a subsequent normal command/response cycle completed normally
• no KASAN report was produced.(CVE-2026-72135)

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

xfrm: xfrminterface: require CAPNET_ADMIN in the device netns for changelink

xfrmichangelink() operates on at most two netns, devnet(dev) and the interface link netns xi->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAPNETADMIN only against dev_net(dev), so a caller privileged there but not in xi->net can rewrite an interface that lives in xi->net.

Gate xfrmichangelink() on rtnldevlinknet_capable() at its top, before any attribute is parsed.(CVE-2026-72136)

In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: Fix frags[] overflow by bounding framecount. tbnetpoll() assembles a multi-frame ThunderboltIP packet into one skb. The first frame goes into the skb linear area and every further frame is added as a page fragment. A packet of framecount frames therefore ends up with framecount - 1 fragments. tbnetcheckframe() only bounds the peer supplied framecount to TBNETRINGSIZE / 4 (64), which is far above MAXSKBFRAGS (17 by default). A peer that sends a packet of 19 or more small frames pushes nrfrags past MAXSKBFRAGS, so skbaddrxfrag() writes past skbshinfo()->frags[] and corrupts memory after the shared info.(CVE-2026-72157)

In the Linux kernel, the following vulnerability has been resolved: mm/mminit: fix uninitialized struct pages for ZONEDEVICE. If DAX memory is hotplugged into an unoccupied subsection of an early section, sectionactivate() reuses the unoptimized boot memmap. However, compoundnr_pages() still assumes that vmemmap optimization is in effect and initializes only the reduced number of struct pages. As a result, the remaining tail struct pages are left uninitialized, which can later lead to unexpected behavior or crashes. Fix this by treating early sections as unoptimized when calculating how many struct pages to initialize.(CVE-2026-72172)

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

SUNRPC: Bound-check xdrbufto_bvec() stores before writing

xdrbuftobvec() writes a biovec into the caller's array before testing whether that slot is in range, and the head branch performs the store with no check at all. When the caller's budget is exactly used up, the next store lands one element past the end of the array. The overflow label returns count - 1, which masks the surplus store but cannot undo it.

rqbvec, the array passed by nfsdvfswrite(), is allocated to exactly rqmaxpages entries with no slack. The OOB store can land in adjacent slab memory; the bvlen and bvoffset fields written there are derived from client-supplied RPC payload sizes.

Move the in-range check ahead of the store in the head, page-loop, and tail branches. With the check at the top of each sequence, count is incremented only after a successful store, so the overflow label can return count directly.(CVE-2026-72217)

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

sunrpc: wait for in-flight TLS handshake callback when cancel loses race

When waitforcompletioninterruptibletimeout() in svctcphandshake() returns 0 (timeout) or -ERESTARTSYS (signal) and tlshandshakecancel() then returns false, handshakecomplete() has won the cancellation race: it has set HANDSHAKEFREQCOMPLETED and is about to invoke svctcphandshakedone(), but the callback's side effects on xptflags and on svsk->skhandshakedone have not yet committed.

The current code reads xpt_flags immediately to decide whether the session succeeded. Two races result.

If the callback has executed setbit(XPTTLSSESSION) but not yet clearbit(XPTHANDSHAKE), svctcphandshake() sees a session, enqueues the transport, and returns. svcxprtreceived() then clears XPTBUSY, a worker thread picks the transport up, the dispatcher in svchandlexprt() observes XPTHANDSHAKE still set, and xpohandshake is invoked a second time. That svctcphandshake() calls initcompletion(&svsk->skhandshakedone) while the original callback concurrently calls completeall() on it, corrupting the embedded swait_queue.

If the callback has set HANDSHAKEFREQCOMPLETED but not yet entered svctcphandshakedone(), svctcphandshake() reads XPTTLSSESSION as clear and tears the connection down even though the handshake is about to succeed.

Wait for the callback to commit before inspecting xptflags. The completion is guaranteed to fire because handshakecomplete() invokes svctcphandshakedone() unconditionally once it has set HANDSHAKEFREQCOMPLETED.(CVE-2026-72221)

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

sunrpc: pin svc_xprt across the asynchronous TLS handshake callback

svctcphandshake() stores the raw svcxprt pointer in tlshandshakeargs.tadata and submits the request through tlsserverhellox509(). The handshake core takes only sockhold(req->hrsk); nothing references the embedding struct svcsock that svctcphandshakedone() reaches via containerof().

Two close races leave the in-flight callback writing through a freed svcsock. svcsockfree() calls tlshandshakecancel() and discards its return value: a false return means handshakecomplete() has already set HANDSHAKEFREQCOMPLETED but hpdone() may not have finished, yet svcsockfree() proceeds to kfree(svsk). The cancel-loser fall-through inside svctcphandshake() itself produces the same window: when waitforcompletioninterruptibletimeout() returns <= 0 (timeout or signal) and tlshandshakecancel() returns false, the function does not drain, returns, and svchandlexprt() calls svcxprtreceived(), which clears XPTBUSY and can drop the last reference. A concurrent close then runs svcsockfree() while svctcphandshakedone() is still updating xptflags and walking svsk->skhandshake_done.

The corruption surfaces as setbit/clearbit RMW into the freed xptflags slab slot and as completeall() walking and writing the freed waitqueueheadt list embedded in skhandshakedone -- a slab-corruption primitive, not a benign read. The path is reachable on any TLS-enabled NFS server whenever a connection close overlaps the tlshd downcall delivery window; the interruptible wait means signal delivery suffices, not just SVCHANDSHAKE_TO expiry.

Take svcxprtget(xprt) immediately before tlsserverhellox509() so the in-flight callback owns its own reference. Release it on the two edges where the callback is guaranteed not to fire -- submission failure from tlsserverhellox509() and a successful tlshandshakecancel() -- and at the tail of svctcphandshakedone() after completeall().

cel: rewrote commit message to describe the actual change

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

batman-adv: retrieve ethhdr after potential skb realloc on RX

pskbmaypull() in batadvinterfacerx() could reallocate the buffer behind the skb. Variables which were pointing to the old buffer need to be reassigned to avoid an use-after-free.

This was done correctly for the VLAN header but missed for the ethernet header which is later used for the TT and AP isolation handling.(CVE-2026-72235)

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

KVM: Move kvmiobusgetdev() locking responsibilities to callers

kvmiobusgetdev() returns a device that is only matched by the address, and nothing else. This can cause a lifetime issue if the matched device is not the expected type, as by the time the caller can introspect the object, it might be gone (the srcu lock having been dropped).

Given that there is only a single user of this helper, the simplest option is to move the locking responsibility to the caller, which can keep the srcu lock held for as long as it wants.

Note that this aligns with other kvmiobus*() helpers, which already require the srcu lock to be held by the callers.(CVE-2026-72282)

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix overflow in passthrough ioctl bounds check. smb2ioctlqueryinfo() validates the PASSTHRUFSCTL response payload before copying it to userspace. The payload offset and length both come from 32-bit fields. The bounds check currently adds OutputOffset and qi.inputbufferlength directly, so the addition can wrap in 32-bit arithmetic before the result is compared against the response buffer length. A malicious server can use a large OutputOffset and a small OutputCount to make the wrapped sum pass the bounds check. The later copytouser() then reads from io_rsp + OutputOffset, outside the response buffer, leading to an out-of-bounds read.(CVE-2026-72310)

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

dm era: fix NULL pointer dereference in metadata_open()

metadataopen() returns NULL when kzallocobj() fails, but the caller eractr() only checks ISERR(md). Since IS_ERR(NULL) returns false, the NULL pointer is treated as a valid result and later assigned to era->md, leading to a NULL pointer dereference when the metadata is accessed.

Fix this by returning ERRPTR(-ENOMEM) on allocation failure, consistent with dm-cache-metadata.c, dm-thin-metadata.c, and dm-clone-metadata.c which all use ERRPTR(-ENOMEM) for the same pattern.(CVE-2026-72316)

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

SUNRPC: pin upper rpcclnt across the TLS connectworker

The TLS connect path has a use-after-free: nothing pins the upper rpcclnt across the delayed connectworker. xsconnect() stores task->tkclient in sockxprt::clnt as a raw pointer and queues the worker; for TLS-secured transports that worker is xstcptlssetupsocket(), which reads several fields out of the saved pointer (cltimeout, clprogram, clprog, clvers, clcred, clstats) to construct the args for the inner handshake rpcclnt.

The xprt does not reference the rpcclnt; the rpcclnt references the xprt. xsdestroy() does cancel the connectworker, but it runs only when the xprt's refcount drops to zero, which cannot happen until the rpcclnt releases its clxprt reference in rpcfreeclientwork(). When a TLS handshake fails fatally (for example, an mTLS mount whose client cert does not match the server), the connecting task is woken with -EACCES and exits, the mount caller invokes rpcshutdownclient(), and the upper rpcclnt is freed before the queued connectworker fires. xstcptlssetupsocket() then dereferences the freed clnt, producing the refcountt underflow Michael Nemanov reported.

Take a reference on the upper rpcclnt in xsconnect() for TLS transports via a new rpcholdclient() helper, and drop it in the connectworker's exit path with rpcreleaseclient(). The xprtlockconnect() / xprtunlockconnect() pairing already serialises xsconnect() with xstcptlssetupsocket(), so the take and release are balanced one-for-one.

The non-TLS connect worker (xstcpsetupsocket) never reads sockxprt::clnt, so leave that path alone and avoid the clnt-holds-xprt-holds-clnt cycle that would otherwise prevent xprt destruction.(CVE-2026-72317)

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

cifs: validate DFS referral string offsets

parsedfsreferrals() validates that the response header and referral array fit in the received buffer, but each referral also contains string offsets supplied by the server.

Those offsets are used to compute the DfsPath and NetworkAddress string pointers without checking whether they still point inside the response buffer. A malformed referral can therefore make the computed pointer exceed the end of the buffer. The resulting negative maxlen is then passed to cifsstrndupfromutf16(), and the non-Unicode path forwards it to kstrndup() as a size_t, allowing strnlen() to read out of bounds.

Validate each string offset before deriving the string pointer.(CVE-2026-72318)

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

ipvs: ensure inner headers in ICMP errors are in headroom

Sashiko points out that after stripping the outer headers with pskbpull() we should ensure the inner IP headers in ICMP errors from tunnels are present in the skb headroom for functions like ipv4updatepmtu(), icmpsend() and IPVSDBG().

Also, add more checks for the length of the inner headers.(CVE-2026-72319)

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

net/tls: Consume empty data records in tlsswread_sock()

A peer may send a zero-length TLS applicationdata record; TLS 1.3 explicitly permits these as a traffic-analysis countermeasure (RFC 8446, Section 5.1). After decryption such a record has fulllen == 0. tlsswreadsock() hands it to the readactor, which has no payload to consume and returns zero. The loop treats a zero return as backpressure (used <= 0), requeues the skb at the head of rxlist, and stops. rxlist is serviced head-first on the next call, so the empty record is dequeued, fails the same way, and is requeued again; every later record on the connection is blocked behind it.

tlsswrecvmsg() does not stall on this: a zero-length data record copies nothing and falls through to consumeskb(). Mirror that in the readsock() path by recognizing an empty data record before the actor runs, consuming it, and continuing.(CVE-2026-72330)

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

qede: fix off-by-one in BD ring consumption on build_skb failure

qederxbuildskb() and qedetparxbuildskb() do not check for a NULL return from qedebuild_skb(). When it returns NULL under memory pressure, the functions still consume a BD from the ring before returning NULL. The callers then recycle additional BDs, resulting in one extra BD being consumed (off-by-one). This desynchronizes the BD ring, which can corrupt DMA page reference counts and lead to SLUB freelist corruption.

Commit 4e910dbe3650 ("qede: confirm skb is allocated before using") added a NULL check inside qedebuildskb() to prevent a NULL pointer dereference, but did not address the missing NULL checks in the callers, making this off-by-one reachable.

Fix this by adding NULL checks for the return value of qedebuildskb() in both qederxbuildskb() and qedetparxbuild_skb(), returning NULL immediately before any BD ring manipulation.(CVE-2026-72339)

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

net/mlx5e: Fix HV VHCA stats agent registration race

mlx5ehvvhcastatscreate() registers the stats agent through mlx5hvvhcaagentcreate(). The helper publishes the agent in hvvhca->agents[type] under agentslock and immediately schedules an asynchronous control invalidation on the HV VHCA workqueue before returning to mlx5e.

The asynchronous invalidation invokes the control agent's invalidate callback, which reads the hypervisor control block and forwards the command to mlx5ehvvhcastatscontrol(). That callback may either:

• call canceldelayedworksync(&priv->statsagent.work), or
• call queuedelayedwork(priv->wq, &sagent->work, sagent->delay).

However, the delayedwork and priv->statsagent.agent are only initialized after mlx5hvvhcaagentcreate() returns to mlx5e:

agent = mlx5_hv_vhca_agent_create(...);   /* publish + invalidate */
...
priv->stats_agent.agent = agent;          /* too late */
INIT_DELAYED_WORK(&priv->stats_agent.work, ...); /* too late */

If the asynchronous control path runs before the two assignments above, it can:

• Operate on an uninitialized delayedwork whose timer.function is NULL. queuedelayedwork() calls addtimer() unconditionally, so when the timer expires the timer softirq invokes a NULL function pointer.
• Re-initialize the timer later through INITDELAYEDWORK() while the timer is already enqueued in the timer wheel, corrupting the hlist (entry.pprev cleared while the previous bucket node still points at this entry).
• When the worker eventually runs, mlx5ehvvhcastatswork() reads sagent->agent (NULL) and dereferences it inside mlx5hvvhcaagentwrite().

Fix this by:

• Initializing priv->statsagent.work before invoking mlx5hvvhcaagent_create(), so the work is always in a valid state when the control callback observes it.
• Adding a struct mlx5hvvhcaagent **ctxupdate out-parameter to mlx5hvvhcaagentcreate(). The helper writes the agent pointer to *ctxupdate before publishing into hvvhca->agents[] and triggering the agentsupdate flow, so any callback subsequently invoked from that flow already sees a valid priv->statsagent.agent. This avoids having the control callback participate in agent initialization.

While at it, access priv->statsagent.agent with READONCE()/WRITEONCE() for the cross-CPU access with the worker, and clear priv->statsagent.buf on the agent_create() failure path.(CVE-2026-72342)

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

bridge: stp: Fix a potential use-after-free when deleting a bridge

The three STP timers are not supposed to be armed while the bridge is administratively down. They are synchronously deactivated when the bridge is put administratively down and the various call sites check for 'IFF_UP' before arming them.

This check is missing from brtopologychange_detection() and it is possible to engineer a situation in which the topology change timer is armed while the bridge is administratively down, resulting in a use-after-free [1] when the bridge is deleted.

Fix by adding the missing check and for good measures synchronously shutdown the three timers when the bridge is deleted.

[1] ODEBUG: free active (active state 0) object: ffff88811662b9b0 object type: timerlist hint: brtopologychangetimerexpired (net/bridge/brstptimer.c:120) WARNING: lib/debugobjects.c:629 at debugprint_object+0x1bc/0x450, CPU#9: ip/359(CVE-2026-72389)

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

seg6: validate SRH length before reading fixed fields

seg6validatesrh() reads fixed SRH fields such as srh->type and srh->hdrlen before checking that the supplied length covers the fixed struct ipv6srhdr fields.

The BPF SEG6 encap path reaches this with a BPF program-supplied pointer and length: bpflwtpushencap() and the SEG6 local BPF ENDB6 and ENDB6ENCAP actions call bpfpushseg6encap(), which forwards the length to seg6validate_srh() with no minimum-size guard. A 2-byte SEG6 encap header can therefore make the validator read srh->type at offset 2 beyond the caller-supplied buffer.

Reject lengths shorter than the fixed SRH at the top of seg6validatesrh(), before any field is read. This fixes the BPF helper path and keeps the common validator robust.(CVE-2026-72400)

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

ice: fix FDIR CTRL VSI resource leak in iceresetall_vfs()

Resetting all VFs causes resource leak on VFs with FDIR filters enabled as CTRL VSIs are only invalidated and not freed. Fix by using icevfctrlvsirelease() instead of icevfctrlinvalidatevsi() which aligns behavior with the iceresetvf() function.

Reproduction: echo 1 > /sys/class/net/$pf/device/sriov_numvfs ethtool -N $vf flow-type ether proto 0x9000 action 0 echo 1 > /sys/class/net/$pf/device/reset(CVE-2026-72425)

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

xfrm: validate selector family and prefixlen during match

syzbot reported a shift-out-of-bounds in xfrmselectormatch() due to AFUNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRMSTATEAFUNSPEC is set).

Fix this by:

• Rejecting mismatched families in xfrmselectormatch.
• Returning false in addr4_match if prefixlen > 32.
• Returning false in addr_match if prefixlen > 128 (prevents overflow).(CVE-2026-72450)

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

apparmor: aalabelalloc use aalabelfree on alloc failure

aalabelalloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aalabelinit().

Use aalabelfree() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.(CVE-2026-72459)

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

apparmor: check label build before nonewprivs test

aachangeprofile() builds a replacement label with fnlabelbuildinscope() before the nonewprivs subset check. The build helper can fail and return NULL or an ERRPTR, but the result was passed to aalabelisunconfinedsubset() before the existing ISERRORNULL() check.

Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.(CVE-2026-72460)

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

xprtrdma: Repost Receive buffers for malformed replies

rpcrdmawcreceive() decrements the transport's Receive count for every completion before it dispatches a successful Receive to rpcrdmareplyhandler(). The handler must post a replacement Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path.

Commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") moved the Receive refill out of rpcrdmawcreceive(), where it had run ahead of every reply, into rpcrdmareplyhandler() so that the responder's credit grant could be parsed before reposting. The bad-version and short-reply exits never reach that refill: they recycle the rep and return without calling rpcrdmapostrecvs().

A remote peer can therefore drain the client's posted Receive queue by sending a sustained stream of replies that are shorter than the fixed transport header or that carry an unrecognized RPC/RDMA version. Each such reply consumes one posted Receive without replacing it. Once the queue empties, the peer's next Send finds no posted Receive and the transport stalls until reconnect.

Route both malformed-reply exits through the shared repost tail after recycling the rep, refilling against buf->rbcredits, the most recent accepted credit grant. Neither exit updates the congestion window, so RPCs admitted under the previous grant remain in flight awaiting replies. A smaller refill target would let a stream of malformed replies ratchet the posted Receive count down to the batch floor while the congestion window still admits rbcredits RPCs; a burst of valid replies to those RPCs could then overrun the posted Receives, and because the client connects with rnrretrycount of zero, a single RNR NAK terminates the connection. Refilling against rbcredits also restores the target that applied to malformed replies before commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") when rpcrdmapostrecvs() computed it from rbcredits internally. rb_credits is at least one from connection establishment onward, so the repost path always keeps Receives posted.(CVE-2026-72464)

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

xprtrdma: Fix bcall rep leak and unbounded peek

rpcrdmaisbcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue.

First, the speculative peek

p = xdr_inline_decode(xdr, 0);
/* five p++ reads follow */

asks xdrinlinedecode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call.

Second, after the post-peek

p = xdr_inline_decode(xdr, 3 * sizeof(*p));
if (unlikely(!p))
        return true;

the short-header arm returns true without calling rpcrdmabcreceive_call(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path:

rpcrdma_reply_handler()
  if (rpcrdma_is_bcall(r_xprt, rep))
          return;        /* bare return, skips out_post */
  ...
out_post:
  rpcrdma_post_recvs(r_xprt, credits + ...);

Because rpcrdmabcreceivecall() never ran, no one took rep, but rpcrdmareplyhandler still bare-returns past rpcrdmarepput() and rpcrdmapostrecvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rballreps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches outpost and rpcrdmapostrecvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs.

Fix by consulting xdr->end after the zero-length peek so the five _be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal outnorqst cleanup chain (rpcrdmarepput() plus rpcrdmapostrecvs()).(CVE-2026-72466)

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

xprtrdma: Decouple req recycling from RPC completion

rlkref formerly served two distinct lifetimes through a single refcount: it gated when a Reply could wake its RPC task, and it gated when an rpcrdmareq could return to its free pool. The marshal path took the Send-side reference only when SGEs needed DMA-unmap (scunmapcount > 0), which made a Send carrying only pre-registered buffers an exception: the Reply handler dropped rl_kref from 1 to 0 and freed the req while the HCA might still be DMA-reading from its send buffer.

Give rlkref a narrower job. The RPC layer takes one reference when slot allocation hands a req out. rpcrdmapreparesendsges() takes a Send-side reference unconditionally after WR preparation succeeds. xprtrdmafreeslot() and xprtrdmabcfreerqst() drop the RPC-layer reference; rpcrdmasendctx_unmap() drops the Send-side reference. The req returns to its free pool only after both owners have signed off.

The existing krefinit(&req->rlkref) call in rpcrdmapreparesendsges() is removed. Initialization moves to the slot-allocation paths (xprtrdmaallocslot and rpcrdmabcrqstget), and the release callback re-arms rlkref before the req returns to a free pool. A re-init in the marshal path would discard the RPC-layer reference that already exists on entry.

Three invariants follow:

• Any rpcrdmareq held by an rpcrqst has rlkref >= 1. xprtrdmaallocslot(), rpcrdmabcrqstget(), and the backlog-wake branch in xprtrdmaallocslot() each krefinit rlkref before publishing the req. Without this invariant, an RPC task that aborts between slot allocation and marshal (gssrefresh failure or signal during callconnect, for example) would drive xprtrelease() -> xprtrdmafreeslot() -> krefput against a refcount of zero, saturating refcountt and stranding the slot.

• The Send-side reference is taken only after WR prep succeeds. A mapping failure in rpcrdmapreparesendsges() runs rpcrdmasendctxcancel(), which DMA-unmaps the sendctx and clears screq without touching rlkref. The sendctx ring walks in rpcrdmasendctxputlocked() and rpcrdmasendctxsdestroy() skip entries with screq == NULL, so a burst of -EIO marshal failures cannot hold reqs off rbsend_bufs.

• The release callback re-arms rl_kref so the next consumer enters with the invariant satisfied.

Replies now complete the RPC directly. rpcrdmareplyhandler() calls rpcrdmacompleterqst() in place of krefput on the non-LocalInv branch. The LocalInv branch already completes the RPC from frwrunmap_async() and is unaffected.

Because Send-side references can now outlive RPC completion, connection teardown drains sendctx entries whose unsignaled Sends never had a later signaled completion to walk the ring. rpcrdmasendctxsdestroy() walks the active range and runs rpcrdmasendctxunmap() on each entry with a non-NULL screq before the request buffers are reset, and is moved ahead of rpcrdmareqsreset() in rpcrdmaxprt_disconnect() so the reqs are still in their pre-reset state when the Send-side refs are released.

The drain creates a teardown-ordering hazard on the backchannel path. With the new lifetime, releasing a bcprealloc req from rpcrdmareqrelease() re-adds it to bcpalist. The disconnect in xprtrdmadestroy() runs after xprtdestroybackchannel() has already emptied bcpalist, so the drained reqs would otherwise leak. xprtrdmadestroy() now runs xprtrdmabcdestroy(xprt, 0) a second time after the disconnect to reclaim them.(CVE-2026-72473)

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

power: supply: core: fix supplied_from allocations

If dts property power-supplies has multiple values, then accessing to psy->supplied_from[i-1] in _powersupplypopulatesuppliedfrom will overrun suppliedfrom array.(CVE-2026-74271)

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

tipc: require net admin for TIPCv2 netlink mutators

TIPCv2 registers mutating generic-netlink operations without admin permission flags. Generic netlink only checks CAPNETADMIN when an operation sets GENLADMINPERM or GENLUNSADMINPERM, so a local unprivileged process can currently change TIPC state through commands such as TIPCNLNETSET, TIPCNLKEYSET, TIPCNLKEYFLUSH, and bearer enable/disable.

The legacy TIPC netlink API already checks netlinknetcapable(..., CAPNETADMIN) for administrative commands. Give the TIPCv2 mutators the equivalent generic-netlink gate. Use GENLUNSADMINPERM, which maps to the same namespace-aware CAPNETADMIN check that netlinknetcapable() performs, so the behaviour matches the legacy path and keeps working for CAPNET_ADMIN holders in a non-initial user namespace (containers).

A QEMU/KASAN repro run as uid/gid 65534 with zero effective capabilities previously succeeded in changing the network id and node identity, setting and flushing key material, and enabling/disabling a UDP bearer. With this patch applied the same operations fail with -EPERM.(CVE-2026-74283)

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

sctp: validate embedded address parameter length

sctpverifyasconf() and sctpverifyparam() only validate ADDIP, DELIP, and SETPRIMARY parameters against a fixed minimum size of sizeof(struct sctpaddipparam) + sizeof(struct sctpparamhdr). This ensures the outer parameter is large enough to contain an embedded address parameter header, but does not verify that the embedded address parameter's declared length fits within the bounds of the outer parameter.

Later, sctpprocessparam() and sctpprocessasconfparam() extract the embedded address parameter and pass it to af->fromaddr_param(), which uses the address parameter length to parse the variable-length address payload. A malformed peer can therefore advertise an embedded address parameter length that exceeds the remaining bytes in the enclosing parameter.

Validate that addrparam->p.length does not exceed the space available after the sctpaddip_param header before processing the embedded address parameter. Reject malformed parameters when the embedded address length extends beyond the enclosing parameter bounds.

This prevents out-of-bounds reads when parsing malformed parameters carried in INIT or ASCONF processing paths.(CVE-2026-74287)

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

bpf: Tighten cgroup storage cookie checks for prog arrays

The fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") is still incomplete. The prog-array compatibility check treats a program with no cgroup storage as compatible with any stored storage cookie. This allows a storage-less program to bridge a tail call chain between an entry program and a storage-using callee even though cgroup local storage at runtime still follows the caller's context, that is, A -> B(no storage) -> C(storage) path.

Requiring exact cookie equality would break the legitimate case of a storage-less leaf program being tail called from a storage-using one. Instead, only accept a zero storage cookie if the program cannot perform tail calls itself. This keeps A -> B(no storage) working while rejecting the A -> B(no storage) -> C(storage) bridge.(CVE-2026-74305)

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

RDMA/rxe: Copy WQE to local buffer in non-SRQ receive path

For non-SRQ QPs, the responder reads WQE fields directly from the shared queue buffer mapped into userspace. This allows a malicious user to modify fields like numsge or sge entries while the kernel is processing the WQE, leading to out-of-bounds reads in rxerespchecklength() and copy_data().

Introduce getrecvwqe() that validates numsge and copies the WQE to a kernel-local buffer before processing, matching the approach already used for SRQ WQEs in getsrqwqe(). The srqwqe buffer is reused since SRQ and non-SRQ paths are mutually exclusive per QP.(CVE-2026-74377)

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

RDMA/rxe: Fix TOCTOU heap overflow in getsrqwqe

getsrqwqe() reads wqe->dma.numsge from the shared receive queue buffer, which is mapped into userspace. It validates numsge against maxsge, but then re-reads the same field to calculate the memcpy size. A concurrent userspace thread can modify numsge between validation and use, causing a heap buffer overflow when copying the WQE into qp->resp.srq_wqe.

Read num_sge into a local variable and use it for both the bounds check and the size calculation.(CVE-2026-74378)

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

RDMA/srpt: fix integer overflow in immediate data length check

immbuf->len is a user-controlled uint32t received from the network. Adding it to immdataoffset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing reqsize to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sginit_one().

Use checkaddoverflow() to detect wrapping before the comparison.(CVE-2026-74394)

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

IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier

mlx5iballoctransportdomain() allocates a transport domain and then may fail in mlx5ibenable_lb(). In that case, the allocated TD is leaked.

Fix this by deallocating the TD when mlx5ibenablelb() returns an error. Also return 0 explicitly in the no-loopback-capability success branch, and move dev->lb.mutex initialization to mlx5ibstageinit_init().(CVE-2026-74397)

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

ipv6: addrconf: bail out of dad_failure when state is no longer POSTDAD

addrconfdadfailure() transitions ifp->state from DAD to POSTDAD via addrconfdadend(), which drops ifp->lock on return. The lock is re-acquired after netinforatelimited(). A concurrent ipv6deladdr() can take the lock in that window, set ifp->state to DEAD and run listdelrcu(&ifp->if_list).

addrconfdadfailure() then overwrites DEAD with ERRDAD at errdad: and schedules a new dadwork. The work calls ipv6del_addr() again, hitting the already-poisoned list entry:

general protection fault: 0000 [#1] SMP NOPTI CPU: 4 PID: 217 Comm: kworker/4:1 Workqueue: ipv6addrconf addrconfdadwork RIP: 0010:ipv6deladdr+0xe9/0x280 RAX: dead000000000122 Call Trace: addrconfdadstop+0x113/0x140 addrconfdadwork+0x28c/0x430 processonework+0x1eb/0x3b0 workerthread+0x4d/0x400 kthread+0x104/0x140 retfromfork+0x35/0x40

Fold the addrconfdadend() logic into addrconfdadfailure() under a single ifp->lock critical section. The STABLEPRIVACY branch temporarily drops ifp->lock around address regeneration, so at lockerrdad: verify the state is still POSTDAD before transitioning to ERRDAD; bail out otherwise to avoid overwriting a state set by another path while the lock was released.(CVE-2026-74398)

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

vxlan: Fix potential null-ptr-deref in vxlangroprepare_receive().

udptunnelsockrelease() could set sk->skuserdata to NULL while vxlangropreparereceive() is running.

Let's check if rcudereferenceskuserdata() is NULL after skbgroremcsum_init().(CVE-2026-74406)