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:

RDMA/rtrs: Fix use-after-free in path file creation cleanup

In the error path of rtrssrvcreatepathfiles(), the sysfs root folders may already have been created and srvpath->kobj may already have been initialized. If a later step fails, the cleanup currently calls kobjectput(&srvpath->kobj) before rtrssrvdestroyoncesysfsrootfolders(srvpath).

kobjectput() may drop the last reference to srvpath->kobj and invoke the release callback, rtrssrvrelease(), which frees srvpath. The following call to rtrssrvdestroyoncesysfsrootfolders(srvpath) then dereferences srvpath internally to access srvpath->srv, resulting in a use-after-free.

This failure path is reached before rtrssrvcreatepathfiles() returns success, so the successful-path lifetime handling is not involved.

Fix this by destroying the sysfs root folders before calling kobjectput(&srvpath->kobj), so srvpath is still valid while the helper accesses it.

This issue was found by a static analysis tool I am developing.

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

serial: 8250dw: unregister 8250 port if clknotifierregister() fails

dw8250probe() registers the 8250 port via serial8250register8250port() and then, if the device has a clock, registers a clock notifier. If clknotifierregister() fails, probe returns the error but leaves the 8250 port registered. The matching serial8250unregisterport() lives in dw8250remove(), which is not called when probe fails, so the port slot stays occupied until the device is rebound or the system is rebooted. The devm-allocated driver data is freed while the port still references it (via the saved privatedata and serialin/serialout callbacks), so any access to that port slot before a rebind is a use-after-free hazard.

Unregister the port on the clknotifierregister() error path.

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:

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:

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:

gcov: use atomic counter updates to fix concurrent access crashes

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.

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

tls: fix handling of zero-length records on the rxlist

Each recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA record

If the next record has different type than what has already been processed we break out of the main processing loop. If the record has already been decrypted (which may be the case for TLS 1.3 where we don't know type until decryption) we queue the pending record to the rxlist. Next recvmsg() will pick it up from there.

Queuing the skb to rxlist after zero-copy decrypt is not possible, since in that case we decrypted directly to the user space buffer, and we don't have an skb to queue (darg.skb points to the ciphertext skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing loop after each non-data record. So we should never zero-copy and then find out that the record type has changed. The corner case we missed is when the initial record comes from rxlist, and it's zero length.

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

btrfs: always detect conflicting inodes when logging inode refs

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

net: stmmac: fix the crash issue for zero copy XDPTX action

There is a crash issue when running zero copy XDPTX action, the crash log is shown below.

[ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000 [ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP [ 216.301694] Call trace: [ 216.304130] dcachecleanpoc+0x20/0x38 (P) [ 216.308308] dmasyncsinglefordevice+0x1bc/0x1e0 [ 216.313351] stmmacxdpxmitxdpf+0x354/0x400 [ 216.317701] stmmacxdprunprog+0x164/0x368 [ 216.322139] stmmacnapipollrxtx+0xba8/0xf00 [ 216.326576] napipoll+0x40/0x218 [ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt

For XDPTX action, the xdpbuff is converted to xdpframe by xdpconvertbufftoframe(). The memory type of the resulting xdpframe depends on the memory type of the xdpbuff. For page pool based xdpbuff it produces xdpframe with memory type MEMTYPEPAGEPOOL. For zero copy XSK pool based xdpbuff it produces xdpframe with memory type MEMTYPEPAGEORDER0. However, stmmacxdpxmitback() does not check the memory type and always uses the page pool type, this leads to invalid mappings and causes the crash. Therefore, check the xdpbuff memory type in stmmacxdpxmitback() to fix this issue.

devlink: rate: Unset parent pointer in devlratenodesdestroy

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

ksmbd: fix slab-use-after-free in ksmbdsmb2sessioncreate

There is a race condition between ksmbdsmb2sessioncreate and ksmbdexpiresession. This patch add missing sessionstablelock while adding/deleting session from global session table.

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

nbd: fix race between timeout and normal completion

If request timetout is handled by nbdrequeuecmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered.

Fix the race by clearing NBDCMDINFLIGHT in nbdrequeuecmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.

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

net/smc: protect link down work from execute after lgr freed

link down work may be scheduled before lgr freed but execute after lgr freed, which may result in crash. So it is need to hold a reference before shedule link down work, and put the reference after work executed or canceled.

The relevant crash call stack as follows: listdel corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smclinkdownwork [smc] RIP: 0010:listdelentryvalid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsemdownwriteslowpath+0x17e/0x470 smclinkdownwork+0x3c/0x60 [smc] processonework+0x1ac/0x350 workerthread+0x49/0x2f0 ? rescuerthread+0x360/0x360 kthread+0x118/0x140 ? kthreadbindmask+0x60/0x60 retfromfork+0x1f/0x30

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

smb: client: fix UAF in smb2reconnectserver()

The Linux kernel CVE team has assigned CVE-2024-35870 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051940-CVE-2024-35870-3c02@gregkh/T

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:

dcache: Limit the minimal number of bucket to two

There is an OOB read problem on dentryhashtable when user sets 'dhashentries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:dlookup+0x56/0x120 Call Trace: dlookup.cold+0x16/0x5d lookupdcache+0x27/0xf0 lookuponeqstrexcl+0x2a/0x180 startdirop+0x55/0xa0 simplestartcreating+0x8d/0xa0 debugfsstartcreating+0x8c/0x180 debugfscreatedir+0x1d/0x1c0 pinctrlinit+0x6d/0x140 dooneinitcall+0x6d/0x3d0 kernelinitfreeable+0x39f/0x460 kernelinit+0x2a/0x260

There will be only one bucket in dentryhashtable when dhashentries is set as one, and dhashshift is calculated as 32 by dcacheinit(). Then, following process will access more than one buckets(which memory region is not allocated) in dentryhashtable: dlookup b = dhash(hash) dentryhashtable + ((u32)hashlen >> dhashshift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> dhashshift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlistblforeachentryrcu(b) hlistblfirstrcu(head) h->first // read OOB!

Fix it by limiting the minimal number of dentryhashtable bucket to two, so that 'dhashshift' won't exceeds the bit width of type u32.

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().

ext4: avoid infinite loops caused by residual data

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).