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: 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: 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:

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:

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:

net: skmsg: preserve sg.copy across SG transforms

The skmsg sg.copy bitmap is part of the scatterlist entry ownership state. A set bit tells skmsgcomputedatapointers() not to expose the entry through writable BPF ctx->data. This protects entries backed by pages that are not private to the skmsg, such as splice-backed file page-cache pages.

Several skmsg transform paths move, copy, split, or compact msg->sg.data[] entries without moving the matching sg.copy bit. This can make an externally backed entry arrive at a new slot with a clear copy bit. A later SKMSG verdict can then expose sgvirt(sge) as writable ctx->data and BPF stores can modify the original page cache.

Keep sg.copy synchronized with sg.data[] whenever entries are transferred, shifted, split, or copied into a new skmsg. Clear the bit when an entry is replaced by a newly allocated private page or freed. This covers the BPF pull/push/pop helpers, skmsgshiftleft/right(), skmsgxfer(), and tlssplitopenrecord(), including the partial tail entry created during TLS open-record splitting.

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:

ipv4: free inetopt and ireqopt after an RCU grace period

tcpv4synrecvsock() transfers ownership of ireq->ireqopt to the child socket (newinet->inetopt) without copying it.

Another cpu can concurrently process a retransmitted SYN for the same request socket, and send a SYNACK from tcpcheckreq(). tcpv4sendsynack() and inetcskroutereq() read ireq->ireqopt under rcureadlock() only, and ipbuildandsendpkt() and ipoptionsbuild() then read opt->optlen twice.

Note that the SYNACK timer itself is not an issue: it holds a reference on its request socket, and inetcskreqskqueuedrop() calls timerdeletesync() before the child can be freed.

Since commit 079096f103fa ("tcp/dccp: install synrecv requests into ehash table"), request sockets are processed without holding the listener lock, so nothing prevents the child socket from being freed while the SYNACK is still being built. TCP child sockets do not have SOCKRCUFREE, and inetsockdestruct() frees inetopt with a plain kfree(), leading to a use-after-free in ipoptionsbuild().

A similar issue exists with request socket migration (net.ipv4.tcpmigratereq=1, or a BPFSKREUSEPORTSELECTORMIGRATE program). reqsktimerhandler() clones the request socket with inetreqskclone(), so that the old request socket and its clone share the same ireqopt, then reqskmigratereset() clears the pointer in the old one. Another cpu holding a reference on the old request socket can still be using these options (sending a SYNACK, or creating a child in tcpv4synrecvsock()) when the clone is freed, and tcpv4reqskdestructor() also uses a plain kfree().

Readers already use RCU, and other paths replacing inetopt (doipsetsockopt(), cipsov4socksetattr()...) already use kfreercu(). Use kfreercu() in inetsockdestruct() and tcpv4reqskdestructor() as well.

IPv6 is not affected by the first issue, because tcpv6synrecvsock() duplicates the options. tcpv6reqskdestructor() has the same migration issue with ipv6opt, which is only set by CALIPSO. This will be addressed in a separate patch.

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

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

RDMA/srpt: Fix srptallocrwctxs() unwind counters

When srptallocrwctxs() fails partway through a multi-buffer indirect descriptor, the unwind path destroys RDMA contexts but leaves stale nrwctx and nrdma values (and a dangling rwctxs pointer). Later sqwravail accounting in srptqueueresponse() or srptwritepending() can then subtract the wrong number of send queue credits.

Reset the counters and clear rwctxs after freeing the heap allocation before returning an error.

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

scsi: target: iscsi: Bound iscsiencodetextoutput() appends to rspbuf

iscsiencodetextoutput() concatenates "key=value\0" records into login->rspbuf, an 8192-byte kzalloc(MAXKEYVALUEPAIRS) buffer allocated in iscsitallocloginsetupbuffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity:

length += sprintf(outputbuf, "%s=%s", er->key, er->value); length += 1; outputbuf = textbuf + length;

The 8192-byte ceiling at iscsitargetcheckloginrequest() bounds the input Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte "a=b\0" pairs, each unknown key expanding to a 16-byte "a=NotUnderstood\0" output record via iscsiaddnotunderstoodresponse(). 2048 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab.

The fix introduces a static iscsiencodetextrecord() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbufsize parameter through iscsiencodetextoutput(). Both call sites in iscsitargethandlecsgzero() (PHASESECURITY) and iscsitargethandlecsgone() (PHASEOPERATIONAL) pass MAXKEYVALUEPAIRS. On overflow the encoder logs the condition, calls iscsireleaseextraresponses() to drop queued records, and returns -1; both caller sites now emit ISCSISTATUSCLSINITIATORERR / ISCSILOGINSTATUSINITERR via iscsittxloginrsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASEOPERATIONAL caller did that; the PHASESECURITY caller is converted to the same shape.)

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

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

sctp: don't free the ASCONF's own transport in DEL-IP processing

sctpprocessasconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctprcv()). For an ASCONF located through its Address Parameter by sctprcvasconflookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address.

sctpprocessasconfparam() rejects a DEL-IP for the packet source address (ADDIP D8, SCTPERRORDELSRCIP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order:

[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]

where L differs from the source. The DEL-IP for L passes the D8 check and calls sctpassocrmpeer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctpassocsetprimary() and sctpassocdelnonprimarypeers(): setprimary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primarypath / activepath, and delnonprimarypeers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transportcount of 0 and primarypath/activepath pointing at freed memory.

Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.

A remote stack overflow in the TIPC networking module. With FORTIFYSOURCE's stricter memcpy() bounds checking, this can be exploited to cause remote DOS via kernel panic on systems using TIPC. Prior to these bounds checks, and with a canary leak (or no CONFIGSTACKPROTECTOR), this can be exploited for RCE.

Reference: https://www.openwall.com/lists/oss-security/2022/02/10/1

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

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

ipv6: icmp: clear skb2->cb[] in ip6errgenicmpv6unreach()

Sashiko AI-review observed:

In ip6errgenicmpv6unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inetskbparm. When skb is cloned into skb2 and passed to icmp6send(), it uses IP6CB(skb2).

IP6CB interprets the IPv4 inetskbparm as an inet6skbparm. The cipso offset in inetskbparm.opt directly overlaps with dsthao in inet6skbparm at offset 18.

If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6send(), mip6addrswap() is called and uses ipv6findtlv(skb, opt->dsthao, IPV6TLVHAO).

This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6destopthao.

Could mip6addrswap() then perform a 16-byte swap that extends past the end of the packet data into skbsharedinfo?

Should the cb array also be cleared in ip6errgenicmpv6unreach() and ip6ip6err() to prevent this?

This patch implements the first suggestion.

I am not sure if ip6ip6err() needs to be changed. A separate patch would be better anyway.

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

net/x25: Fix overflow when accumulating packets

Add a check to ensure that x25sock.fraglen does not overflow.

The fraglen also needs to be resetted when purging fragmentqueue in x25clearqueues().

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

ip6tunnel: clear skb2->cb[] in ip4ip6err()

Oskar Kjos reported the following problem.

ip4ip6err() calls icmpsend() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6skbparm. icmpsend() passes IPCB(skb2) to ipoptionsecho(), which interprets that cb[] region as struct inetskbparm (IPv4). The layouts differ: inet6skbparm.nhoff at offset 14 overlaps inetskbparm.opt.rr, producing a non-zero rr value. ipoptionsecho() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->data, a fixed 40-byte stack buffer (IPOPTIONSDATAFIXEDSIZE).

To fix this we clear skb2->cb[], as suggested by Oskar Kjos.

Also add minimal IPv4 header validation (version == 4, ihl >= 5).

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

libceph: define and enforce CEPHMAXKEYLEN

When decoding the key, verify that the key material would fit into a fixed-size buffer in processauthdone() and generally has a sane length.

The new CEPHMAXKEYLEN check replaces the existing check for a key with no key material which is a) not universal since CEPHCRYPTONONE has to be excluded and b) doesn't provide much value since a smaller than needed key is just as invalid as no key -- this has to be handled elsewhere anyway.

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

net/x25: Fix potential double free of skb

When allocskb fails in x25queuerxframe it calls kfreeskb(skb) at line 48 and returns 1 (error). This error propagates back through the call chain:

x25queuerxframe returns 1 | v x25state3machine receives the return value 1 and takes the else branch at line 278, setting queued=0 and returning 0 | v x25processrxframe returns queued=0 | v x25backlogrcv at line 452 sees queued=0 and calls kfreeskb(skb) again

This would free the same skb twice. Looking at x25backlogrcv:

net/x25/x25in.c:x25backlogrcv() { ... queued = x25processrxframe(sk, skb); ... if (!queued) kfreeskb(skb); }

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

net: mana: Fix TOCTOU double-fetch of hwcmsgid from DMA buffer

In manahwcrxeventhandler(), resp->response.hwcmsgid is read from DMA-coherent memory and bounds-checked, then manahwchandleresp() re-reads the same field from the same DMA buffer for testbit() and pointer arithmetic.

DMA-coherent memory is mapped uncacheable on x86 and is shared, unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes directly to host-visible memory. A H/W can modify the value between the check and the use, bypassing the bounds validation.

Fix this by reading hwcmsgid exactly once using READONCE() into a stack-local variable in manahwcrxeventhandler(), and passing the validated value as a parameter to manahwchandleresp().

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:

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

nvmet-tcp: add bounds checks in nvmettcpbuildpduiovec

nvmettcpbuildpduiovec() could walk past cmd->req.sg when a PDU length or offset exceeds sgcnt and then use bogus sg->length/offset values, leading to copytoiter() GPF/KASAN. Guard sgidx, remaining entries, and sg->length/offset before building the bvec.

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

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

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

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

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

net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels

seg6inputcore() and rplinput() call ip6routeinput() which sets a NOREF dst on the skb, then pass it to dstcachesetip6() invoking dsthold() unconditionally. On PREEMPTRT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpurt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence:

ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6inputcore(,skb)/rplinput(skb) dstcacheget() -> miss ip6routeinput(skb) -> ip6polroute(,skb,flags) [RT6LOOKUPFDSTNOREF in flags] -> FIB lookup resolves fib6nh [nhid=N route] -> rt6makepcpuroute() [creates pcpurt, refcount=1] pcpurt->sernum = fib6sernum [fib6sernum=W] -> cmpxchg(fib6nh.rt6ipcpu, NULL, pcpurt) [slot was empty, store succeeds] -> skbdstsetnoref(skb, dst) [dst is pcpurt, refcount still 1]

rtgenidbumpipv6() -> bumps fib6sernum [fib6sernum from W to Z] ip6routeoutput() -> ip6polroute() -> FIB lookup resolves fib6nh [nhid=N] -> rt6getpcpuroute() pcpurt->sernum != fib6sernum [W <> Z, stale] -> prev = xchg(rt6ipcpu, NULL) -> dstrelease(prev) [prev is pcpurt, refcount 1->0, dead]

dst = skbdst(skb) [dst is the dead pcpurt] dstcachesetip6(dst) -> dsthold() on dead dst -> WARN / use-after-free

For the race to occur, ksoftirqd must be preemptible (PREEMPTRT without PREEMPTRTNEEDSBHLOCK) and a concurrent task must be able to release the pcpurt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6nh and its rt6ipcpu entry.

Fix seg6inputcore() and rplinput() by calling skbdstforce() after ip6routeinput() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6routeoutput() already returns a refcounted dst.

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

RDMA/rxe: Validate pad and ICRC before payloadsize() in rxercv

rxercv() currently checks only that the incoming packet is at least headersize(pkt) bytes long before payloadsize() is used.

However, payloadsize() subtracts both the attacker-controlled BTH pad field and RXEICRCSIZE from pkt->paylen:

payloadsize = pkt->paylen - offset[RXEPAYLOAD] - bthpad(pkt) - RXEICRCSIZE

This means a short packet can still make payloadsize() underflow even if it includes enough bytes for the fixed headers. Simply requiring headersize(pkt) + RXEICRCSIZE is not sufficient either, because a packet with a forged non-zero BTH pad can still leave payloadsize() negative and pass an underflowed value to later receive-path users.

Fix this by validating pkt->paylen against the full minimum length required by payloadsize(): headersize(pkt) + bthpad(pkt) + RXEICRCSIZE.