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:

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:

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:

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:

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.

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

batman-adv: tt: fix negative lastchangesetlen

batadvpivtt::lastchangesetlen len was declared as s16, but the field is never intended to hold a negative value. When a value greater than 32767 is assigned, it wraps to a negative signed integer.

In batadvsendmyttresponse(), lastchangesetlen is temporarily widened to s32. The incorrectly negative s16 value propagates into the s32, causing batadvttpreparetvlvlocaldata() to allocate a full sized buffer but populates only a small portion of it with the collected changeset. All remaining bits are kept uninitialized.

Using an u16 avoids this type confusion and ensures that no (negative) sign extension is performed in batadvsendmyttresponse().

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

net: ethernet: cortina: Carry over frag counter

The gmacrx() NAPI poll function assembles packets in an SKB from a ring buffer.

If the ring buffer gets completely emptied during a poll cycle, we exit gmacrx(), but the packet is not yet completely assembled in the SKB, yet the fragment counter fragnr is reset to zero on the next invocation.

Solve this by making the RX fragment counter a part of the port struct, and carry it over between invocations.

Reset the fragment counter only right after calling napigrofrags(), on error (after calling napifreefrags()) or if stopping the port.

Reset it in some place where not strictly necessary just to emphasize what is going on.

This was found by Sashiko during normal patch review.

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

net: ethernet: cortina: Make RX SKB per-port

The SKB used to assemble packets from fragments in gmacrx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both.

Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead.

Zero the pointer once we call napigrofrags(), on error (after calling napifreefrags()) or if the port is stopped.

Zero it in some place where not strictly necessary just to emphasize what is going on.

This was found by Sashiko during normal patch review.

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

net: tls: prevent chain-after-chain in plain text SG

Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link:

This would create a chain where the wrap link points directly to another chain link. The scatterlist API sgnext iterator does not recursively resolve consecutive chain links.

meaning this is illegal input to crypto.

The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap:

end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap]

Skip the wrapping in this case.

TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0. This avoids the chain-after-chain.

Move the wrap chaining before marking END and chaining off content type, that feels like more logical ordering to me, but should not matter from functional perspective.

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

net: tls: fix off-by-one in sgchain entry count for wrapped skmsg ring

When an skmsg scatterlist ring wraps (sg.end < sg.start), tlspushrecord() chains the tail portion of the ring to the head using sgchain(). An extra entry in the sg array is reserved for this:

struct skmsgsg { [...] / The extra two elements: 1) used for chaining the front and sections when the list becomes partitioned (e.g. end < start). The crypto APIs require the chaining; 2) to chain tailer SG entries after the message. / struct scatterlist data[MAXMSGFRAGS + 2];

The current code uses MAXSKBFRAGS + 1 as the ring size:

sgchain(&msgpl->sg.data[msgpl->sg.start], MAXSKBFRAGS - msgpl->sg.start + 1, msgpl->sg.data);

This places the chain pointer at

sgchain(data[start], (MAXSKBFRAGS - msgstart + 1) .. = &data[start] + (MAXSKBFRAGS - msgstart + 1) - 1 = data[start + (MAXSKBFRAGS - start + 1) - 1] = data[MAXSKBFRAGS]

instead of the true last entry. This is likely due to a "race" of the commit under Fixes landing close to commit 031097d9e079 ("bpf: skmsg, zap ingress queue on psock down")

Convert to ARRAYSIZE and drop the data[start] / - start (as suggested by Sabrina).

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

pNFS: Fix use-after-free in pnfsupdatelayout()

When hitting the NFSLAYOUTRETURN branch in pnfsupdatelayout(), the code calls pnfspreparetoretrylayoutget(lo). If it succeeds, pnfsputlayouthdr(lo) is called before tracepnfsupdatelayout(), which still references 'lo'. This results in a use-after-free when the tracepoint accesses lo's fields.

Fix this by moving the tracepoint call before pnfsputlayouthdr(lo).

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

nfsd: release layout stid on setlease failure

nfs4allocstid() publishes the new stid into cl->clstateids via idralloccyclic() under cllock before returning to nfsd4alloclayoutstateid(). When nfsd4layoutsetlease() then fails, the error path frees the layout stateid directly with kmemcachefree() without ever calling idrremove(), leaving the IDR slot pointing at freed slab memory. Any subsequent IDR walker (statesshow, client teardown) dereferences the dangling pointer.

The correct teardown for an IDR-published stid is nfs4putstid(), which removes the IDR slot under cllock, dispatches scfree (nfsd4freelayoutstateid) to release ls->lsfile via nfsd4closelayout(), and drops the nfs4file reference in its tail.

A second issue blocks that switch: nfsd4freelayoutstateid() unconditionally inspects ls->lsfencework via delayedworkpending() under lslock, but INITDELAYEDWORK(&ls->lsfencework, ...) currently runs only after the setlease call. On the setlease-failure path the destructor would touch an uninitialized delayedwork.

nfsd4alloclayoutstateid() nfs4allocstid() / idralloccyclic under cllock / nfsd4layoutsetlease() / fails / nfs4putstid() nfsd4freelayoutstateid() delayedworkpending(&ls->lsfencework) / needs INIT / nfsd4closelayout() / nfsdfileput(ls->lsfile) / putnfs4file()

Fix by hoisting the lsfenced / lsfencedelay / INITDELAYEDWORK initialization above the nfsd4layoutsetlease() call, and replace the manual nfsdfileput + putnfs4file + kmemcachefree cleanup with a single nfs4putstid(stp).

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

net: rds: clear isends on setup unwind

The RDS IB connection teardown path is written so it can run during partial startup and on repeated shutdown attempts. It uses NULL pointers to distinguish resources that are still owned from resources that have already been released.

When rdsibsetupqp() fails after allocating isends but before allocating irecvs, the sendsout path frees isends without clearing the pointer. A later shutdown pass can still treat that stale pointer as a live send ring allocation.

Clear isends after vfree() in the error unwind path so the existing shutdown logic continues to use the correct ownership state.

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

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

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

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

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

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

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

RDMA/srp: bound SRPRSP sense copy by the received length

srpprocessrsp() copies sense data from rsp->data + respdatalen, where respdatalen is the full 32-bit value supplied by the SRP target and is never checked against the number of bytes actually received (wc->bytelen). The copy length is bounded to SCSISENSEBUFFERSIZE, so at most 96 bytes are copied, but the source offset is not bounded.

A malicious or compromised SRP target on the InfiniBand/RoCE fabric that the initiator has logged into can return an SRPRSP with SRPRSPFLAGSNSVALID set and a large respdatalen. The receive buffer is allocated at the target-chosen maxtiiulen, so the source of the sense copy lands past the bytes actually received; with respdatalen near 0xFFFFFFFF it is gigabytes past the buffer and the read faults.

Copy the sense data only if it has not been truncated, that is, only if the response header, the response data, and the sense region fit within the bytes actually received; otherwise drop the sense and log. The in-tree iSER and NVMe-RDMA receive paths already bound their parse by wc->bytelen; this brings ibsrp into line with them.

IB/isert: Reject login PDUs shorter than ISERHEADERSLEN

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

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

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

net/rds: Restrict use of RDS/IB to the initial network namespace

Prevent using RDS/IB in network namespaces other than the initial one. The existing RDS/IB code will not work properly in non-initial network namespaces.

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

ppp: require CAPNETADMIN in target netns for unattached ioctls

/dev/ppp open is currently authorized against file->fcred->userns, while unattached administrative ioctls operate on current->nsproxy->netns.

As a result, a local unprivileged user can create a new user namespace with CLONENEWUSER, gain CAPNETADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace.

Require CAPNETADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls.

This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case.

dm cache policy smq: fix missing locks in invalidating cache blocks