In the Linux kernel, the following vulnerability has been resolved:
tipc: fix out-of-bounds read in broadcast Gap ACK blocks
A broadcast PROTOCOL/STATEMSG can carry a Gap ACK blocks record in its data area. tipcgetgapackblks() only verifies that the record's len field is self-consistent with its ugackcnt/bgackcnt counts (sz == structsize(p, gacks, ugackcnt + bgackcnt)); it does not check that the record actually fits in the message data area, msgdatasz().
The unicast caller tipclinkprotorcv() bounds it ("if (glen > dlen) break;"), but the broadcast caller tipcbcastsyncrcv() discards the returned size, so tipclinkadvancetransmq() copies the record off the receive skb with an attacker-controlled count:
thisga = kmemdup(ga, structsize(ga, gacks, ga->bgackcnt), GFPATOMIC);
A TIPC neighbour that negotiated TIPCGAPACKBLOCK triggers it with one ordinary broadcast STATEMSG (msgbcackinvalid() clear), sized so its data area is short, carrying a Gap ACK record with len = 0x400, bgackcnt = 0xff and ugackcnt = 0. len then equals structsize(p, gacks, 255), so the consistency check passes and ga is non-NULL; kmemdup() reads structsize(ga, gacks, 255) = 1024 bytes out of the much smaller skb:
BUG: KASAN: slab-out-of-bounds in kmemdupnoprof+0x48/0x60 Read of size 1024 at addr ffff0000c7030d38 by task poc864/69 Call trace: kmemdupnoprof+0x48/0x60 tipclinkadvancetransmq+0x86c/0xb80 tipclinkbcackrcv+0x19c/0x1e0 tipcbcastsyncrcv+0x1c4/0x2c4 tipcrcv+0x85c/0x1340 tipcl2rcvmsg+0xac/0x104 The buggy address belongs to the object at ffff0000c7030d00 which belongs to the cache skbuffsmallhead of size 704 The buggy address is located 56 bytes inside of allocated 704-byte region [ffff0000c7030d00, ffff0000c7030fc0)
The copied-out bytes are subsequently consumed as gap/ack values, but the read is already out of bounds at the kmemdup() regardless of how they are used.
The unicast STATE path drops such a message: "if (glen > dlen) break;" skips the rest of STATEMSG handling and the skb is freed. Make the broadcast path drop it too. tipcbcastsyncrcv() now bounds the record against msgdatasz() and, when it does not fit, reports it back through tipcnodebcsyncrcv() to tipcrcv() so the skb is discarded rather than processed. ga is not cleared on this path: ga == NULL already means "legacy peer without Selective ACK", a distinct legitimate state.
In the Linux kernel, the following vulnerability has been resolved:
crypto: krb5 - filter out async aead implementations at alloc
krb5aeadencrypt(), krb5aeaddecrypt() in rfc3961simplified.c and rfc8009encrypt(), rfc8009decrypt() in rfc8009aes2.c set a NULL completion callback and treat any negative return from cryptoaead{encrypt,decrypt}() as terminal, falling through to kfreesensitive(buffer). When the encryptname resolves to an async AEAD instance the request returns -EINPROGRESS, the buffer is freed while the backend's worker still holds a pointer, and the worker dereferences the freed slab on completion.
KASAN report under UML+SLUB with a synthetic async aead backend bound to krb5->encryptname:
BUG: KASAN: slab-use-after-free in t5stubcomplete+0x7d/0xc7
The helpers were written synchronously, so filter the async instances out at allocation time instead of plumbing cryptowaitreq() through every call site.
Reachable via net/rxrpc/rxgk.c, fs/afs/cmsecurity.c and net/ceph/crypto.c on systems with an async AEAD provider bound to the krb5 enctype name.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: IPIP tunnel hardware offload is not yet support
No driver supports for IPIP tunnels yet, give up early on setting up the hardware offload for this scenario.
This patch adds a stub that can be enhanced to add more configuration that are currently not supported. As of now, the offload work is enqueued to the worker, then ignored if the hardware offload configuration is not supported.
Check the NFFLOWHW flag to know if this entry was already tried once to be offloaded so this is not retried on refresh when unsupported. Move NFFLOWHW flag check to nfflowoffloadadd(). If this NFFLOWHW flag is unset the del and stats variants are never called.
This can be updated later on to skip hardware offload work to be queued in case hardware offload does not support it.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add permission checks for FSCTLDUPLICATEEXTENTSTOFILE
The FSCTLDUPLICATEEXTENTSTOFILE arm of smb2ioctl() overwrites the destination file's data via vfsclonefilerange() with neither the share-level KSMBDTREECONNFLAGWRITABLE check nor a per-handle fp->daccess check that the other write-bearing arms carry. A client can overwrite destination data on a read-only share, or from a handle opened with only FILEWRITEATTRIBUTES (which still yields an FMODEWRITE filp). FILEWRITEATTRIBUTES-only destination handle overwrote the file's data via the clone. Add both checks, matching the FSCTLSETSPARSE permission fix; require FILEWRITEDATA since this writes data.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: serialize QUERYDIRECTORY requests per file
smb2querydir() stores a pointer to its stack-allocated private data in the ksmbdfile readdirdata. Concurrent QUERYDIRECTORY requests using the same file handle can overwrite this pointer while an iteratedir() callback is still using it, resulting in a stack use-after-free.
Add a per-file mutex and hold it while accessing the shared directory enumeration state. The lock covers scan restart, dot entry state, readdirdata setup and iteration, and response construction. This prevents another request from replacing readdirdata.private before the current request has finished using it and also serializes the shared file position.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: run set info with opener credentials
SMB2 SETINFO handlers call path-based VFS helpers after checking the access mask granted to the SMB handle. Those helpers perform their owner, inode permission and LSM checks using the current ksmbd worker credentials.
Run the complete SETINFO dispatch with the credentials captured when the handle was opened. This also removes the separate security information credential setup and keeps all SETINFO classes under one credential scope.
Direct overridecreds() is used because it can nest with the request credential overrides already used by rename and link helpers.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: use opener credentials for ADS I/O
Alternate data streams are stored as xattrs. Unlike regular file I/O, their read and write paths therefore call VFS xattr helpers which recheck inode permissions and LSM policy using the current task credentials.
Run ADS I/O with the credentials captured when the SMB handle was opened.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: use opener credentials for delete-on-close
Delete-on-close can be completed by deferred or durable handle teardown, where no request work is available. Both the base-file unlink and the ADS xattr removal consequently run with the ksmbd worker credentials and can bypass filesystem permission checks.
Run both operations with the credentials captured in struct file when the handle was opened. This preserves the authenticated user's fsuid, fsgid, supplementary groups and capability restrictions at final close.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix query directory replay double-free
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2querydirectoryinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix queryinfo() replay double-free
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2queryinfoinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double-free in SMB2ioctl() replay
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2ioctlinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix change notify replay double-free
A response-bearing attempt can return a replayable error and free its response buffer. If SMB2notifyinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.
Reset response bookkeeping before each attempt to prevent the stale free.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix double-free in SMB2flush() replay
SMB2flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifssendrecv() stores a replacement response, flushexit will free the stale response pointer a second time.
Reinitialize respbuftype and rspiov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests.
In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject fragmented frames in devmap
Devmap broadcast redirects clone the packet for all but the last destination.
For native XDP, that clone path copies only the linear xdpframe data, while fragmented frames keep skbsharedinfo in tailroom outside the linear area. Cloning such a frame leaves XDPFLAGSHASFRAGS set but without valid frag metadata, and the later free path can interpret uninitialized tail data as skbsharedinfo, leading to an out-of-bounds access during frame return.
Reject fragmented native XDP frames in devmapenqueueclone().
Add the same restriction to the generic XDP clone path in devmapredirectclone(). Generic XDP represents fragmented packets as nonlinear skbs, and rejecting them here keeps clone-based broadcast support aligned between native and generic XDP.
In the Linux kernel, the following vulnerability has been resolved:
nvmet-auth: validate reply message payload bounds against transfer length
nvmetauthreply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes.
A malicious NVMe-oF initiator can craft a DHCHAPREPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2hl) or performs the host response memcmp.
With DH authentication configured, the OOB pointer is passed directly to sginitone() and read by cryptokppcomputesharedsecret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication.
Add bounds validation ensuring sizeof(data) + 2hl + dhvlen <= tl before any access to the variable-length fields.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page
nvmetexecutediscgetlogpage() validates only the dword alignment of the host-supplied Log Page Offset (lpo). The 64-bit offset is then added to a small kzalloc'd buffer that holds the discovery log page and the result is passed straight to nvmetcopytosgl(), which memcpy()s datalen bytes out to the host with no source-side bound check:
u64 offset = nvmetgetlogpageoffset(req->cmd); / 64-bit host / sizet datalen = nvmetgetlogpagelen(req->cmd); / 32-bit host / ... if (offset & 0x3) { ... } / only check / ... alloclen = sizeof(hdr) + entrysize discoverylogentries(req); buffer = kzalloc(alloclen, GFPKERNEL); ... status = nvmetcopytosgl(req, 0, buffer + offset, datalen);
The Discovery controller is unauthenticated -- nvmethostallowed() returns true unconditionally for the discovery subsystem -- so the call is reachable pre-authentication by any TCP/RDMA/FC peer that can reach the nvmet target. With a discovery log page of ~1 KiB, an attacker requesting up to 4 KiB starting at offset == alloclen reads the next slab page out and gets its content returned over the fabric (an empirical run on a default nvmet-tcp loopback target leaked 81 canonical kernel pointers in one Get Log Page response). Pointing the offset at unmapped kernel memory faults the in-kernel memcpy and crashes (or panics, on paniconoops=1) the target host instead.
The attacker-controlled source-side offset pattern "nvmetcopytosgl(req, 0, buffer + ATTACKEROFFSET, ...)" is unique to nvmetexecutediscgetlogpage in the entire nvmet codebase: every other Get Log Page handler in admin-cmd.c either ignores lpo (and silently starts every response at offset 0) or tracks a local destination offset with a fixed source pointer.
Validate the host-supplied offset against the log page size, cap the copy length to what is actually available, and zero-fill any remainder of the host transfer buffer. The zero-fill matches the existing short-response pattern in nvmetexecutegetlogchangedns() (admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log page contains.
In the Linux kernel, the following vulnerability has been resolved:
spi: fsl-lpspi: terminate the RX channel on TX prepare failure path
When dmaengineprepslavesg() fails for the TX channel, the error path terminates the TX DMA channel but leaves the RX channel running. Since the RX channel was already submitted and issued prior to preparing the TX descriptor, returning -EINVAL causes the SPI core to unmap the DMA buffers while the RX DMA engine continues writing to them, leading to potential memory corruption or use-after-free.
Terminate the RX channel before returning on the TX prepare failure path.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdmawritesg
When the server answers an RTRS READ, rdmawritesg() builds the source scatter/gather entry for the IBWRRDMAWRITE that returns data to the peer. Its length is taken directly from the wire descriptor:
plist->length = le32tocpu(id->rdmsg->desc[0].len);
rdmsg points into the chunk buffer that the remote peer filled via RDMA-WRITE-WITH-IMM (rtrssrvrdmadone() -> processioreq() -> processread()), so desc[0].len is attacker-controlled and, before this change, was only rejected when zero. The source address is the fixed chunk start (dmaaddr[msgid]) and the source lkey is the PD-wide localdmalkey, which is not tied to the chunk's MR mapping, so the verbs layer does not constrain the transfer length to maxchunksize. msgid and off are bounded against queuedepth and maxchunksize in rtrssrvrdmadone(), but desc[0].len is a separate field that was not checked against the chunk size.
A peer that advertises desc[0].len larger than maxchunksize can make the posted RDMA write read past the chunk's mapped region. The resulting behaviour depends on the IOMMU configuration: with no IOMMU or in passthrough mode the read may extend into memory adjacent to the chunk and be returned to the peer, which can disclose host memory; with a translating IOMMU the out-of-range access is expected to fault and abort the connection. In either case the transfer exceeds what the protocol permits and is driven by a remote peer.
Reject a descriptor length above maxchunksize, mirroring the existing off >= maxchunksize bound in rtrssrvrdmadone(). Legitimate clients do not exceed it: the client sets desc[0].len to its MR length, which is capped at the negotiated maxiosize (maxchunksize - MAXHDRSIZE).
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: bound Read Response placement to the RREAD length
In drivers/infiniband/sw/siw/siwqprx.c, siwprocrresp() places each inbound Read Response DDP segment at sge->laddr + wqe->processed and then accumulates wqe->processed, but it never checks the running total against the sink buffer length on continuation segments. siwchecksge() resolves and validates the sink memory only on the first fragment (the if (!mem) branch), and siwrrespcheckntoh() compares the cumulative length against wqe->bytes only on the final segment (the !frx->moreddpsegs guard).
A connected siw peer that answers an outstanding RREAD with Read Response segments that keep the DDP Last flag clear, carrying more total payload than the RREAD requested, drives wqe->processed past the validated sink buffer; the next siwrxdata() call writes out of bounds at sge->laddr + wqe->processed. siw runs iWARP over ordinary routable TCP, so the peer is the remote end of an established RDMA connection and needs no local privilege.
Bound every segment before placement, exactly as siwprocsend() and siwprocwrite() already do for their tagged and untagged paths, and terminate the connection with a base-or-bounds DDP error when the Read Response would overrun the sink buffer.
This is the second receive-path length fix for this file. A separate change rejects an MPA FPDU length that underflows the per-fragment remainder in the header decode; that guard does not cover this case, because here each individual segment length is self-consistent and only the accumulated placement offset overruns the buffer.
In the Linux kernel, the following vulnerability has been resolved:
block: recompute nrintegritysegments in blkinsertclonedrequest
blkinsertclonedrequest() already recomputes nrphyssegments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virtboundarymask, segboundarymask, or maxsegmentsize than the top queue, in which case blkrqcountintegritysg() against the bottom queue produces a different count than the cached rq->nrintegritysegments inherited from the source request by blkrqprepclone().
When the cached count is lower than the bottom queue's actual count, blkrqmapintegritysg() trips
BUGON(segments > rq->nrintegritysegments);
on dispatch. The same families of stacked setups that motivated the existing nrphyssegments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this.
Mirror the nrphyssegments handling: when the request carries integrity, recompute nrintegritysegments against the bottom queue and reject the request if it exceeds the bottom queue's maxintegritysegments. blkrqcountintegritysg() and queuemaxintegritysegments() are both already available via <linux/blk-integrity.h>, which blk-mq.c includes.
This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting.
In the Linux kernel, the following vulnerability has been resolved:
netfs: Fix potential UAF in netfsunlockabandonedreadpages()
netfsunlockabandonedreadpages(rreq) accesses the index of the folios it is wanting to unlock and compares that to rreq->nounlockfolio so that it doesn't unlock a folio being read for netfsperformwrite() or netfswritebegin().
However, given that netfsunlockabandonedreadpages() is called after NETFSRREQINPROGRESS is cleared, the one folio that it's not allowed to dereference is the one specified by ->nounlockfolio as ownership immediately reverts to the caller.
Fix this by storing the folio pointer instead and using that rather than the index. Also fix netfsunlockreadfolio() where the same applies.
In the Linux kernel, the following vulnerability has been resolved:
idpf: fix readdevclklock spinlock init in idpfptpinit()
In idpfptpinit(), readdevclklock is initialized after ptpscheduleworker() had already been called (and after idpfptpsettime64() could reach the lock). The PTP aux worker fires immediately upon scheduling and can call into idpfptpreadsrcclkregdirect(), which takes spinlock(&ptp->readdevclklock) on an uninitialized lock, triggering the lockdep "non-static key" warning:
[12973.796587] idpf 0000:83:00.0: Device HW Reset initiated [12974.094507] INFO: trying to register non-static key. ... [12974.097208] Call Trace: [12974.097213] <TASK> [12974.097218] dumpstacklvl+0x93/0xe0 [12974.097234] registerlockclass+0x4c4/0x4e0 [12974.097249] ? lockacquire+0x427/0x2290 [12974.097259] lockacquire+0x98/0x2290 [12974.097272] lockacquire+0xc6/0x310 [12974.097281] ? idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097311] ? lockdephardirqsonprepare+0xde/0x190 [12974.097318] ? finishtaskswitch.isra.0+0xd2/0x350 [12974.097330] ? pfxptpauxkworker+0x10/0x10 [ptp] [12974.097343] rawspinlock+0x30/0x40 [12974.097353] ? idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097373] idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097391] ? kthreadworkerfn+0x88/0x3d0 [12974.097404] ? kthreadworkerfn+0x4e/0x3d0 [12974.097411] idpfptpupdatecachedphctime+0x26/0x120 [idpf] [12974.097428] ? rawspinunlockirq+0x28/0x50 [12974.097436] idpfptpdoauxwork+0x15/0x20 [idpf] [12974.097454] ptpauxkworker+0x20/0x40 [ptp] [12974.097464] kthreadworkerfn+0xd5/0x3d0 [12974.097474] ? pfxkthreadworkerfn+0x10/0x10 [12974.097482] kthread+0xf4/0x130 [12974.097489] ? pfxkthread+0x10/0x10 [12974.097498] retfromfork+0x32c/0x410 [12974.097512] ? pfxkthread+0x10/0x10 [12974.097519] retfromforkasm+0x1a/0x30 [12974.097540] </TASK>
Move the call to spinlockinit() up a bit to make sure readdevclklock is not touched before it's been initialized.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftinner: release locallock before re-enabling softirqs
Quoting sashiko: In the error path, localbhenable() is called before localunlocknestedbh().
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: close durable scavenger races against mfplist lookups
ksmbddurablescavenger() has two related races against any walker that iterates fci->mfplist, including ksmbdlookupfdinode() (used by ksmbdvfsrename) and the share-mode checks in fs/smb/server/smbcommon.c.
(1) fp->node list-head reuse. Durable-preserved handles can remain linked on fci->mfplist after session teardown so share-mode checks still see them while the handle is reconnectable. The scavenger collected expired handles by adding fp->node to a local scavengerlist after removing them from the global durable idr. Because fp->node is the same listhead used by mfplist, listadd(&fp->node, &scavengerlist) overwrites the mfplist links and corrupts both lists. CONFIGDEBUGLIST can report this on the share-mode walk path.
(2) Refcount race against mfplist walkers. The scavenger qualifies an expired durable handle with atomicread(&fp->refcount) > 1 and fp->conn under globalft.lock, removes fp from globalft, then drops globalft.lock before unlinking fp from mfplist and freeing it. During that gap fp is still linked on mfplist with fstate == FPINITED. ksmbdlookupfdinode() under mlock read calls ksmbdfpget() (atomicincnotzero on refcount that is still 1) and takes a live reference; the scavenger then unlinks and frees fp while the holder owns a reference, leading to UAF on the holder's subsequent ksmbdfdput() and on any field reads performed by a concurrent share-mode walker that iterates mfplist without taking ksmbdfpget() (smbcheckpermdleases-like paths).
Fix both:
Stop reusing fp->node as a scavenger-private list node. Remove one expired handle from globalft under globalft.lock, take an explicit transient reference, drop the lock, unlink fp->node from mfplist under fci->mlock, then drop both the durable lifetime and transient references with atomicsubandtest(2, &fp->refcount). If the scavenger is the last putter the close runs there; otherwise an in-flight holder that already raced through the mfplist lookup owns the final close via its ksmbdfdput() path. The one-at-a-time disposal can rescan the durable idr when multiple handles expire in the same pass, but durable scavenging is a background expiration path and the final full scan recomputes mintimeout before the next wait.
Clear fp->persistentid inside ksmbdremovedurablefd() right after idrremove(), so a delayed final close from a holder that snatched fp does not re-issue idrremove() on a persistent id that idralloccyclic() in ksmbdopendurablefd() may have already handed out to a brand-new durable handle.
Bypass the per-conn openfilescount decrement in putfdfinal() when fp is detached from any session table (fp->conn cleared by sessionfdcheck() at durable preserve -- paired with the volatileid clear at unpublish, so checking fp->conn alone is sufficient). The walker that owns the final close runs from an unrelated work->conn whose stats.openfilescount never tracked this durable fp; without this guard the holder would underflow that unrelated counter.
The two races are folded into one patch because patch (1) alone cleans up the corrupted list but leaves a deterministic UAF window for mfplist walkers that the transient-reference and persistentid discipline in (2) close; bisecting onto an intermediate state would land on a UAF that pre-patch chaos merely made less reproducible.
Validation: CONFIGDEBUGLIST coverage for the listhead reuse path. KASAN-enabled direct SMB2 durable-handle coverage that exercised ksmbddurablescavenger() and non-NULL ksmbdlookupfdinode() returns while durable handles expired under concurrent rename lookups, with no KASAN, UAF, list-corruption, ODEBUG, or WARNING reports. ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ioam: refresh hdr pointer before ioam6event()
Reported by Sashiko:
In ipv6hopioam(), the hdr pointer is initialized to point into the skb's linear data buffer. Later, the code calls skbensurewritable(), which might reallocate the buffer:
if (skbensurewritable(skb, optoff + 2 + hdr->optlen)) goto drop;
/ Trace pointer may have changed / trace = (struct ioam6tracehdr )(skbnetworkheader(skb) + optoff + sizeof(hdr));
ioam6filltracedata(skb, ns, trace, true);
ioam6event(IOAM6EVENTTRACE, devnet(skb->dev), GFPATOMIC, (void )trace, hdr->optlen - 2);
If the skb is cloned or lacks sufficient linear headroom, skbensurewritable() will invoke pskbexpandhead(), which reallocates the skb's data buffer and frees the old one, invalidating pointers to it. While the code recalculates the trace pointer immediately after the call to skbensurewritable(), it fails to recalculate the hdr pointer.
This patch fixes the above by recalculating the hdr pointer before passing hdr->optlen to ioam6event(), so that we avoid any UaF.
In the Linux kernel, the following vulnerability has been resolved:
net: bcmgenet: keep RBUF EEE/PM disabled
Setting RBUFEEEEN | RBUFPMEN in RBUFENERGYCTRL breaks the RX path on GENET hardware once MAC EEE becomes active. RX traffic stops flowing while the link stays up and the usual descriptor/RX error counters remain quiet. In that state the MAC still accepts frames (rbufovflowcnt keeps climbing) but RBUF no longer forwards them to DMA, so rxpackets is no longer incremented at the netdev level. On some boards the corruption ends up as a paging fault in skbreleasedata via bcmgenetrxpoll on an LPI exit.
Reproduced on Pi 4B (BCM2711 + BCM54213PE) and confirmed by Florian Fainelli on an internal Broadcom 4908-family board with the same crash signature. RBUFPMEN is not publicly documented.
This shows up more often now that physupporteee() enables EEE by default, but it also affects older kernels as soon as TX LPI is turned on via ethtool, so it is not specific to recent changes.
Always clear RBUFEEEEN | RBUFPMEN in bcmgeneteeeenableset so the bits stay off across resets. UMAC and TBUF setup is left alone so TX-side EEE keeps working.
In the Linux kernel, the following vulnerability has been resolved:
ixgbevf: fix use-after-free in VEPA multicast source pruning
ixgbevfcleanrxirq() prunes frames whose source MAC matches the VF's own address (VEPA multicast workaround) by freeing the skb and continuing to the next descriptor:
devkfreeskbirq(skb); continue;
The skb pointer is declared outside the while loop and persists across iterations. Because the continue skips the "skb = NULL" reset at the bottom of the loop, the next iteration enters the "else if (skb)" path and calls ixgbevfaddrxfrag() on the freed skb, dereferencing skbshinfo(skb)->nrfrags - a use-after-free in NAPI softirq context.
The sibling driver iavf already handles this correctly by nulling the pointer before continuing. Apply the same pattern here.
I do not have ixgbevf hardware; the bug was found by static analysis (scandropcontinueloops.py + semgrep dropcontinueinloop, multi-tool corroboration with the highest score in the scan). The UAF was confirmed under KASAN by loading a test module that reproduces the exact code pattern (alloc skb, kfreeskb, then read skbshinfo(skb)->nrfrags):
BUG: KASAN: slab-use-after-free in ixgbevfuaftestinit+0x100/0x1000 Read of size 8 at addr 000000006163ae78 by task insmod/30 freed 208-byte region [000000006163adc0, 000000006163ae90)
QEMU emulates igb (82576) but not ixgbe (82599), and the igbvf VF driver does not include the VEPA source pruning path, so a full end-to-end reproduction with emulated hardware was not possible.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-its: Reject restored DTE with out-of-range numeventidbits
Userspace can restore an ITS Device Table Entry whose Size field encodes more EventID bits than the virtual ITS supports. The live MAPD path rejects that state, but vgicitsrestoredte() accepts it and stores the out-of-range value in dev->numeventidbits.
Reject restored DTEs with numeventidbits > VITSTYPERIDBITS before allocating the device. This mirrors the MAPD check and prevents the restored state from reaching vgicitsrestoreitt(), where the unchecked value can be converted into an oversized scanitstable() range.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Reject MPA FPDU length underflow before signed receive math
A malicious connected siw peer can send an iWARP FPDU whose MPA length field (chdr->mpalen, 16 bit big-endian, peer-controlled) is smaller than the fixed DDP/RDMAP header for the announced opcode. Soft-iWARP parses the full header in siwgethdr() based on iwarppktinfo[opcode] .hdrlen, but never compares mpalen against that header length.
siwtcprxdata() then derives
srx->fpdupartrem = be16tocpu(mpalen) - fpdupartrcvd + MPAHDRSIZE;
where fpdupartrcvd equals iwarppktinfo[opcode].hdrlen at this point. For a tagged WRITE (hdrlen 16, MPAHDRSIZE 2) the smallest on-wire mpalen of 0 yields fpdupartrem = -14, and any mpalen below hdrlen - MPAHDRSIZE underflows to a negative int.
The signed value then flows into siwprocwrite()/siwprocrresp() as
bytes = min(srx->fpdupartrem, srx->skbnew);
is handed to siwcheckmem() as an int len (whose interval check addr + len > mem->va + mem->len is satisfied for a valid base when len is negative), and reaches siwrxdata() -> siwrxkva() / siwrxumem() -> skbcopybits() as a signed copy length. The header copy branch in skbcopybits() promotes that to sizet, producing a multi-gigabyte read.
KASAN under a KUnit harness that drives the real kernel TCP receive path -- a loopback AFINET socketpair, the malformed FPDU written via kernelsendmsg, skdataready firing in softirq, tcpreadsock dispatching to siwtcprxdata -- reports:
BUG: KASAN: use-after-free in skbcopybits+0x284/0x480 Read of size 4294967295 at addr ffff888... Call Trace: skbcopybits siwrxkva siwrxdata siwcheckmem siwprocwrite siwtcprxdata tcpreadsock siwqpllpdataready tcpdataready tcpdataqueue
Add the missing invariant at the earliest point where the peer header is fully assembled. iwarppktinfo[].hdrlen - MPAHDRSIZE is exactly the value the siw transmitter uses as the minimum mpalen for each opcode (drivers/infiniband/sw/siw/siwqp.c:33), so this matches the protocol contract. Out-of-range FPDUs terminate the connection with TERMERRORLAYERLLP / LLPETYPEMPA / LLPECODEFPDUSTART -- which is RFC 5044 Section 8 error code 3 ("Marker and ULPDU Length fields do not agree on the start of an FPDU"), the correct framing-error class for this inconsistency.
In the Linux kernel, the following vulnerability has been resolved:
batman-adv: tt: fix TOCTOU race for reported vlans
The local TT based TVLV is generated by first checking the number of VLANs which have at least one TT entry. A new buffer with the correct size for the VLANs is then allocated. Only then, the list of VLANs s used to fill the VLAN entries in the buffer. During this time, the meshifvlanlistlock is held. But the actual number of TT entries of each VLAN can still increase during this time - just not the number of VLANs in the list.
But the prefilter used in the buffer size calculation might still cause an increase of the number of VLANs which need to be stored. Simply because a VLAN might now suddenly have at least one entry when it had none in the pre-alloc check - and then needs to occupy space which was not allocated.
It is better to overestimate the buffer size at the beginning and then fill the buffer only with the VLANs which are not empty.