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

KVM: arm64: vgic: Fix race between LPI release and re-registration

Fix a potential race between decrementing an LPI's reference count and evicting that structure from the LPI xarray.

LPI structures are maintained in the VGIC LPI xarray (dist->lpixa). When the reference count of an LPI structure drops to zero, vgicreleaselpilocked() removes the structure from the xarray and frees it under the xarray lock.

However, the release of an LPI can race with a concurrent LPI re-registration with the same INTID via vgicaddlpi() on another CPU, since the reference count drop and the xarray eviction are not performed in a single atomic step. This can happen e.g. if the guest issues a DISCARD while the LPI is still referenced from a vCPU's active-pending list (aplist), and the same INTID is re-mapped via MAPTI.

Particularly, vgicreleaselpilocked() is called from two distinct paths: direct release via vgicputirq(), and deferred release via vgicreleasedeletedlpis(). During direct release, the issue can result in deleting a newly registered LPI from the xarray:

CPU0 (Releasing LPI) CPU1 (Adding new LPI) ==================== ===================== vgicputirq() vgicputirq() refcountdecandtest() vgicaddlpi() xalockirqsave() oldirq = xaload(.., intid) vgictrygetirqref(oldirq) == false new IRQ inserted --> xastore(.., intid, ..) xaunlockirqrestore() xalockirqsave(); vgicreleaselpilocked() xaerase(.., irq->intid) <-- BUG: new IRQ is erased kfreercu(oldirq)

During the deferred release path, the old IRQ can be leaked:

CPU0 (Releasing LPI) CPU1 (Adding new LPI) ==================== ===================== vgicputirqnorelease() vgicputirq() refcountdecandtest() irq->pendingrelease = true vgicaddlpi() xalockirqsave() oldirq = xaload(.., intid) vgictrygetirqref(oldirq) == false BUG: old IRQ overwritten --> xastore(.., intid, ..) xaunlockirqrestore()

vgicreleasedeletedlpis() xalockirqsave() xaforeach() { .. } <-- old IRQ with pendingrelease = true is gone, so it cannot be released

To fix the direct release path, move the reference count drop inside the xarray lock, making sure that vgicaddlpi() never encounters the to-be-released LPI.

In the deferred release path, the refcount drop must happen under a raw spinlock, so the xarray lock cannot be grabbed, and the same solution does not work. Instead, update vgicaddlpi(), so that if it evicts an LPI from the xarray, it takes on the responsibility of freeing it. Consequently, an LPI may now be freed concurrently after a deferred release drops the refcount, so accessing the pendingrelease field is no longer safe from use-after-free. Delete all uses of the flag, and update vgicreleasedeletedlpis() to identify orphaned LPIs purely based on their refcount.

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

ocfs2: validate fast symlink target during inode read

ocfs2validateinodeblock() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem. Fast symlinks need the same treatment.

A zero-cluster symlink is treated as a fast symlink and later read through pagegetlink() and ocfs2fastsymlinkreadfolio(). That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio. If a corrupt dinode stores an isize that does not fit the inline area or omits the terminating NUL at isize, that copy reads past the end of the inode block buffer.

Reject zero-cluster symlink dinodes whose isize exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at isize when the inode block is validated. This keeps malformed fast symlinks from reaching the read path.

Validation reproduced this kernel report: KASAN use-after-free in ocfs2fastsymlinkreadfolio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace: dumpstacklvl+0x66/0xa0 (?:?) printreport+0xce/0x630 (?:?) ocfs2fastsymlinkreadfolio+0x12c/0x1f0 (fs/ocfs2/inode.c:?) srsoaliasreturnthunk+0x5/0xfbef5 (?:?) virtaddrvalid+0x19f/0x330 (?:?) kasanreport+0xe0/0x110 (?:?) kasancheckrange+0x105/0x1b0 (?:?) asanmemcpy+0x23/0x60 (?:?) filemapreadfolio+0x27/0xe0 (?:?) filemapreadfolio+0x35/0xe0 (?:?) doreadcachefolio+0x138/0x230 (?:?) pagegetlink+0x26/0x110 (?:?) pagegetlink+0x2e/0x70 (?:?) vfsreadlink+0x15e/0x250 (?:?) touchatime+0x4d/0x370 (?:?) doreadlinkat+0x186/0x200 (?:?) douseraddrfault+0x65a/0x890 (?:?) x64sysreadlink+0x46/0x60 (?:?) dosyscall64+0x115/0x6a0 (arch/x86/entry/syscall64.c:87) entrySYSCALL64afterhwframe+0x77/0x7f (?:?)

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

netfs: Fix missing barriers when accessing stream->subrequests locklessly

The list of subrequests attached to stream->subrequests is accessed without locks by netfscollectreadresults() and netfscollectwriteresults(), and then they access subreq->flags without taking a barrier after getting the subreq pointer from the list. Relatedly, the functions that build the list don't use any sort of write barrier when constructing the list to make sure that the NETFSSREQINPROGRESS flag is perceived to be set first if no lock is taken.

Fix this by:

(1) Add a new listaddtailrelease() function that uses a release barrier to set the pointer to the new member of the list.

(2) Add a new listfirstentryornullacquire() function that uses an acquire barrier to read the pointer to the first member in a list (or return NULL).

(3) Use listaddtailrelease() when adding a subreq to ->subrequests.

(4) Use listfirstentryornullacquire() when initially accessing the front of the list (when an item is removed, the pointer to the new front iterm is obtained under the same lock).

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

nvme: nvme-fc: Ensure ->ioerrwork is cancelled in nvmefcdeletectrl()

nvmefcdeleteassocation() waits for pending I/O to complete before returning, and an error can cause ->ioerrwork to be queued after cancelworksync() had been called. Move the call to cancelworksync() to be after nvmefcdeleteassociation() to ensure ->ioerrwork is not running when the nvmefcctrl object is freed. Otherwise the following can occur:

[ 1135.911754] listdel corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/listdebug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:listdelentryvalidorreport.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] <TASK> [ 1136.063179] ? showtraceloglvl+0x1b0/0x2f0 [ 1136.067540] ? showtraceloglvl+0x1b0/0x2f0 [ 1136.071898] ? movelinkedworks+0x4a/0xa0 [ 1136.075998] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.081744] ? diebody.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? dotrap+0xca/0x110 [ 1136.091789] ? doerrortrap+0x65/0x80 [ 1136.095543] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.101289] ? excinvalidop+0x50/0x70 [ 1136.105127] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.110874] ? asmexcinvalidop+0x1a/0x20 [ 1136.115059] ? listdelentryvalidorreport.cold+0xf/0x6f [ 1136.120806] movelinkedworks+0x4a/0xa0 [ 1136.124733] workerthread+0x216/0x3a0 [ 1136.128485] ? pfxworkerthread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? pfxkthread+0x10/0x10 [ 1136.139657] retfromfork+0x31/0x50 [ 1136.143236] ? pfxkthread+0x10/0x10 [ 1136.146988] retfromforkasm+0x1a/0x30 [ 1136.150915] </TASK>

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

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

tls: always refresh the queue when reading sock

After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry.

BUG: KASAN: slab-use-after-free in tlsstrpcheckrcv+0x898/0x9a0 [tls] (net/tls/tlsstrp.c:436 net/tls/tlsstrp.c:530 net/tls/tlsstrp.c:544) Read of size 4 at addr ffff888013085750 by task tls/13529

CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme Call Trace: kasanreport+0xca/0x100 tlsstrpcheckrcv+0x898/0x9a0 [tls] tlsrxrecwait+0x2c9/0x8d0 [tls] tlsswrecvmsg+0x40f/0x1aa0 [tls] inetrecvmsg+0x1c3/0x1f0

Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.fulllen").

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

nfsd: nfsd4spomustallow() must check this is a v4 compound request

If the request being processed is not a v4 compound request, then examining the cstate can have undefined results.

This patch adds a check that the rpc procedure being executed (rqprocinfo) is the NFSPROC4COMPOUND procedure.

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

sctp: keep chunk->transport in step with the list it is queued on

sctpoutqflushrtx() moves a gap-acked chunk onto another transport's transmitted list without updating chunk->transport:

if (chunk->tsngapacked) { listmovetail(&chunk->transmittedlist, &transport->transmitted); continue; }

The chunk then sits on a live transport's list while chunk->transport still names a different one. If that transport is removed - sctpassocrmpeer() from an ASCONF Delete-IP - sctptransportfree() RCU-frees it and the chunk is left with a dangling pointer. sctpassocrmpeer() scrubs peer->transmitted and asoc->outqueue.outchunklist, but the chunk is on neither.

The pointer is not followed while tsngapacked is set. A SACK that reneges on the TSN clears the flag, and the next SACK reaches

tchunk->transport->flightsize -= sctpdatasize(tchunk);

inside the freed transport. KASAN reports a slab-use-after-free read in sctpchecktransmitted(), freed from sctpassocrmpeer(). Both the removal and the SACKs come from the association peer.

Set chunk->transport at the move. The ordinary resend path needs nothing: it reaches its listmovetail() only after sctppacketappendchunk() returned SCTPXMITOK, and sctppacketappendchunk() has rebound the chunk by then.

Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

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

tls: rx: restore msgiter before TLS 1.3 optimistic retry

tlsdecryptsg() advances msg->msgiter when it maps user pages for the optimistic TLS 1.3 zero-copy path. If the decrypted record turns out not to be unpadded application data, tlsdecryptsw() retries into a kernel skb, but leaves the iterator advanced.

The subsequent copy from the skb then writes decrypted bytes again at a later point in the caller iovecs while recvmsg() reports only the post-retry length. A TLS peer can trigger this after the receiver enables TLSRXEXPECTNOPAD.

Revert the iterator by the number of bytes consumed by the optimistic mapping before retrying without zero-copy.

Add a selftest which sends a TLS 1.3 control record with TLSRXEXPECTNOPAD enabled and verifies that recvmsg() does not overwrite later iovecs beyond the returned length.

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

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

ip6ip6err() clones an outer IPv6 ICMP error skb, pulls it to the quoted inner IPv6 packet, and then passes the clone to icmpv6send(). The clone still carries the outer packet's inet6skbparm in skb->cb.

If the outer packet had a Home Address Option, IP6CB(skb2)->dsthao remains non-zero after skbpull(). icmpv6send() later calls mip6addrswap(), which uses that stale dsthao offset against the quoted inner packet. A malformed inner destination-options header can then make the HAO lookup and address swap run past the end of the quoted packet and corrupt skbsharedinfo.

Clear skb2->cb[] before pulling the quoted inner IPv6 packet so the reply path does not reuse metadata left by the outer IPv6 stack.

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

dibs: initialise dibs->lock in dibsdevalloc()

dibs->lock is initialised by dibsdevadd(), but a dibs device can already take interrupts before that call: ismprobe() runs ismdevinit(), and hence requestirq(), before it calls dibsdevadd(). No client can have registered a dmb at that point, so no dmb interrupt can occur, but a GID event interrupt can, and ismhandleirq() takes dibs->lock unconditionally on entry, before it inspects anything else.

Initialise the lock in dibsdevalloc() instead, so that it is valid as soon as a driver can publish the device to its interrupt handler.

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

inet: frags: publish queues before arming timer

inetfragcreate() arms the fragment queue timer before inserting the queue into the fqdir rhashtable. If the namespace fragment timeout is zero or negative, the timer can run before the queue is published.

The timer callback then marks the queue complete, tries to remove a node that is not in the hash table yet, and drops the anticipated hash reference. Creation can subsequently publish the completed queue without restoring that reference, leaving a stale hash node after the caller drops the remaining reference.

Publish the queue first and arm the timer while holding the queue lock. This makes timer expiry wait until the queue is visible in the hash table, so inetfragkill() can remove the node and balance the hash reference.

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

udp: fix potential use-after-free in tunnel segmentation

skbudptunnelsegment() gets the UDP header before ensuring the tunnel header is in the skb head. If the pull reallocates skb->head, the saved UDP header pointer is no longer valid.

Get the UDP header after the pull to avoid a potential use-after-free.

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

bpf, skmsg: fix verdict skdataready racing with ktls rx

skpsockstrpdataready() already checks tlsswhasctxrx() and defers to psock->saveddataready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running skskb program types with ktls").

skpsockverdictdataready() has no equivalent guard. When a socket is inserted into a sockmap (BPFSKSKBVERDICT) before TLS RX is configured, tlsswstrparserarm() saves skpsockverdictdataready as rxctx->saveddataready. On data arrival:

tlsdataready -> tlsstrpdataready -> tlsrxmsgready -> saveddataready() = skpsockverdictdataready() -> tcpreadskb() drains skreceivequeue via skbunlink() without calling tcpeatskb(), so copiedseq is not advanced.

tlsstrpmsgload() then finds tcpinq() >= fulllen (stale), calls tcprecvskb() on the now-empty queue, hits WARNONONCE(!first), and returns with rxctx->strp.anchor.fraglist pointing at a psock-owned (potentially freed) skb. tlsdecryptsg() subsequently walks that fraglist: use-after-free.

Apply the same fix as skpsockstrpdataready(): if a TLS RX context is present, call psock->saveddataready (sockdefreadable) to wake recv() waiters and return immediately, leaving the receive queue untouched. TLS retains sole ownership of the queue and decrypts the record normally through tlsswrecvmsg().

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

tcp: fix stale per-CPU tcptwisn leak enabling ISN prediction

Blamed commit moved the TIMEWAIT-derived ISN from the skb control block to a per-CPU variable, assuming the value would always be consumed by tcpconnrequest() for the same packet that wrote it. That assumption is violated by multiple drop paths between the producer (thiscpuwrite(tcptwisn, isn) in tcpv{4,6}rcv()) and the consumer (tcpconnrequest()):

- minttl / minhopcount check - xfrm policy check - tcpinboundhash() MD5/AO mismatch - tcpfilter() eBPF/SOATTACHFILTER drop - th->syn && th->fin discard in tcprcvstateprocess() TCPLISTEN - pspskrxpolicycheck() in tcpv{4,6}dorcv() - tcpchecksumcomplete() in tcpv{4,6}dorcv() - tcpv{4,6}cookiecheck() returning NULL

When a packet is dropped on any of these paths, tcptwisn is left set.

The next SYN processed on the same CPU then consumes the non zero value in tcpconnrequest(), receiving a potentially predictable ISN.

This patch moves back tcptwisn to skb->cb[], getting rid of the per-cpu variable.

Note that tcpv{4,6}fillcb() do not set it.

Very litle impact on overall code size/complexity:

$ scripts/bloat-o-meter -t vmlinux.old vmlinux.new add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7) Function old new delta tcpv6rcv 3038 3042 +4 tcpv4rcv 3035 3039 +4 tcpconnrequest 2938 2923 -15 Total: Before=24436060, After=24436053, chg -0.00%

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

ksmbd: fix durable reconnect error path file lifetime

After a durable reconnect succeeds, ksmbdreopendurablefd() republishes the same ksmbdfile into the session volatile-id table. If smb2open() then takes a later error path, cleanup first calls ksmbdfdput(work, fp) and then unconditionally calls ksmbdputdurablefd(dhinfo.fp).

In this case fp and dhinfo.fp are the same object. The first put drops the reconnect lookup reference, but the final durable put can run ksmbdclosefd(NULL, fp). Because the final close is not session-aware, it can free the file object without removing the volatile-id entry that was just published into the session table.

Use the session-aware put for the final reconnect drop when the reconnect had already succeeded and the error path is cleaning up the republished file. Earlier reconnect failures, before fp is assigned to dhinfo.fp, keep using the durable-only put path.

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

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:

KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page

Explicitly clear role.invalid when deriving a child shadow page's role from its parent to harden against bugs elsewhere in KVM, as violating KVM's invariant that invalid pages are NOT on the list of active MMU pages leads to use-after-free due to kvmmmupreparezappage() using listadd() instead of listmove() when processing an invalid shadow page, i.e. makes a bad situation far worse.

Yell loudly if the parent is invalid, as it means KVM has missed a validity check, i.e. KVM is attempting to map memory using an invalid/obsolete root, but continue on as the child is otherwise still a valid shadow page.

================================================================== BUG: KASAN: slab-use-after-free in kvmmmugetshadowpage+0x1817/0x1860 [kvm] Write of size 8 at addr ff11000153dd1368 by task repro/853

CPU: 1 UID: 1000 PID: 853 Comm: repro Not tainted 7.2.0-rc2-3aec122bdcaf-next-vm #5 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x4b/0x70 printreport+0x153/0x49c kasanreport+0xbc/0xf0 kvmmmugetshadowpage+0x1817/0x1860 [kvm] mmuallocroot+0x141/0x320 [kvm] kvmmmuload+0x612/0x20f0 [kvm] kvmarchvcpuioctlrun+0x3dd5/0x6150 [kvm] kvmvcpuioctl+0x5e4/0x10d0 [kvm] x64sysioctl+0x131/0x1b0 dosyscall64+0x67/0x5f0 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK>

Allocated by task 853: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 kasanslaballoc+0x5f/0x70 kmemcacheallocnoprof+0xfe/0x2e0 kvmmmutopupmemorycache+0x135/0x530 [kvm] paging64pagefault+0x318/0x1e30 [kvm] kvmmmudopagefault+0x21d/0x630 [kvm] kvmmmupagefault+0x18c/0x17b0 [kvm] kvmarchvcpuioctlrun+0x1f35/0x6150 [kvm] kvmvcpuioctl+0x5e4/0x10d0 [kvm] x64sysioctl+0x131/0x1b0 dosyscall64+0x67/0x5f0 entrySYSCALL64afterhwframe+0x4b/0x53

Freed by task 853: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x43/0x70 kmemcachefree+0xe2/0x400 kvmmmucommitzappage.part.0+0x1e2/0x310 [kvm] kvmmmufreeroots+0x283/0x560 [kvm] kvmarchvcpuioctlrun+0x33c8/0x6150 [kvm] kvmvcpuioctl+0x5e4/0x10d0 [kvm] x64sysioctl+0x131/0x1b0 dosyscall64+0x67/0x5f0 entrySYSCALL64afterhwframe+0x4b/0x53

Bluetooth: mgmt: hold reference for hciconn in mgmtpendingcmds

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

sctp: close UDP tunnel sockets during netns teardown

procsctpdoudpport() starts per-net SCTP UDP tunneling sockets when net.sctp.udpport is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed.

Close the UDP tunnel sockets from sctpctrlsockexit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.

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

net/smc: check smcdv2extoffset when receiving proposal msg

When receiving proposal msg in server, the field smcdv2extoffset in proposal msg is from the remote client and can not be fully trusted. Once the value of smcdv2extoffset exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks the value of smcdv2extoffset before using it.

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

net/smc: check v2extoffset/eidcnt/ismgidcnt when receiving proposal msg

When receiving proposal msg in server, the fields v2extoffset/ eidcnt/ismgidcnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2extoffset, once exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks the fields v2extoffset/eidcnt/ismgidcnt before using them.

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

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

scsi: target: iscsi: Reserve a terminator byte for the login payload

iscsitargetcheckloginrequest() rejects a login PDU whose DataSegmentLength exceeds MAXKEYVALUEPAIRS, but the test is '>' and login->reqbuf is allocated with exactly MAXKEYVALUEPAIRS bytes. Since iscsitgetloginrx() receives payloadlength + padding bytes, where

padding = ((-payloadlength) & 3);

any payloadlength from 8189 to 8192 fills the whole 8192 byte buffer. The write stays in bounds, but no byte is left for a NUL terminator.

The buffer is subsequently consumed as a C string. In the CHAP path chapcheckalgorithm() calls kstrdup(astr), and extractparam() calls strstr(inbuf, pattern) followed by strlensemi(), none of which take a length. convertnulltosemi() additionally rewrites every embedded NUL to ';', so even a payload made of well formed NUL separated key=value records is left without a terminator. These walk past the end of the object into adjacent slab memory. It is reachable by an unauthenticated initiator against a portal configured for CHAP; when authentication is not required iscsiloginzerotsihs2() rewrites AuthMethod to None and the CHAP path is never entered.

Allocate one extra byte. kzalloc() zeroes it and nothing ever writes to it, as every writer copies to offset 0 for at most MAXKEYVALUEPAIRS bytes, so the buffer is always terminated.

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

nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU

nvmettcptryrecvpdu() reads a PDU header into the fixed 128-byte queue->pdu union, then computes the remaining payload length as

queue->left = hdr->hlen - queue->offset + hdgst;

and reads that many more bytes into &queue->pdu + queue->offset, without ever bounding the result against sizeof(queue->pdu).

A struct nvmetcpicreqpdu is itself 128 bytes, exactly the size of the union. Once a header digest has been negotiated (hdgst = 4), a second ICReq passes the hlen == nvmettcppdusize() check but yields queue->left = 128 - 8 + 4 = 124, so bytes 8..132 are written into the 128-byte buffer -- 4 bytes past its end, over queue->hdrdigest and queue->datadigest. Those bytes are attacker-controlled (an ICReq carries no digest), and the duplicate ICReq is only rejected later, after the overflow. A remote unauthenticated host can thus corrupt kernel memory adjacent to the receive buffer.

Reject any PDU whose declared length would read past the end of queue->pdu before the second recv.

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

xfrm: Fix skb double-free in xfrmdevdirectoutput()

A return value other than 1 from localout() means that the skb has been consumed or its ownership was transferred. xfrmdevdirectoutput() nevertheless frees the skb on this path, causing a double-free when netfilter drops the packet and invalidating any other owner.

Return the localout() result directly, matching the ownership handling in xfrmoutputresume().

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

net: skbuff: don't skbtxerror() the source skb in skbzerocopy()

skbzerocopy() copies frags from @from into @to. On an skborphanfrags() failure it calls skbtxerror(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFLALLZEROCOPY, including the SKBFLSHAREDFRAG page-ownership marker.

Both callers already report the failure on their own drop path. nfnetlinkqueue does it at nlaputfailure, and Open vSwitch does it in the flow-miss drop arm of ovsdpprocesspacket(), so nothing is lost by dropping it here.

On Open vSwitch's OVSACTIONATTRUSERSPACE path the skb is not freed on this error: doexecuteactions() ignores outputuserspace()'s return value and, unless the upcall was the last action, keeps forwarding the same skb through the flow's remaining actions. The uarg is completed while that skb is still in flight, telling the producer its buffers are free, and SKBFLSHAREDFRAG is cleared on an skb the rest of the stack still handles. That flag is what makes espinput() call skbcowdata() instead of decrypting in place, so a later local ESP delivery can decrypt over frags the skb does not own privately.

Leave error reporting to the callers.

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

sctp: stop processing a packet once its association is deleted

sctpendpointbhrcv() looks the association up only when chunk->asoc is NULL, and caches the result in chunk->asoc and chunk->transport without taking a reference.

A packet that matches no association is handed to the endpoint, so a peer can bundle COOKIE ECHO, SHUTDOWN and SHUTDOWN ACK in one packet. The COOKIE ECHO creates the association, the SHUTDOWN chunk caches it, and with the outqueue empty the SHUTDOWN ACK reaches sctpsfdo92final(), so the association and its transports are freed.

The endpoint loop has no counterpart to the asoc->base.dead check in sctpassocbhrcv(). The next chunk writes to lasttimeheard in the freed transport and is then passed to sctpdosm() with the freed association. The transport is freed through RCU, so this needs the packet to come off the socket backlog, where the loop runs in task context.

The endpoint loop cannot do the same check: it holds no reference on the association, so reading asoc->base.dead would itself be a use-after-free. Mark the packet for discard in the command interpreter, just before it deletes the association. That is also before sctpinqfree() releases the chunk on the association receive path.

sctpsfdo524dupcook() issues SCTPCMDDELETETCB for the temporary association, while the one the packet belongs to stays alive. A restarting peer can bundle DATA behind its COOKIE ECHO, so compare against chunk->asoc and leave that case alone.

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

netfilter: nfconntracksip: widen NAT rewrite delta to s32 in siphelptcp()

siphelptcp() stores the size change of each NAT-rewritten SIP message in s16 diff and accumulates it in s16 tdiff, but a single message can grow by more than S16MAX while the packet stays under the 65535 enlargeskb() limit: nfnatsip() rewrites every matching URI, and a long Contact list expands the message by tens of kilobytes. diff then wraps, and "datalen = datalen + diff - msglen" yields a huge unsigned datalen, so the next iteration's ctsipgetheader() reads past the linearized skb tail.

Widen diff, tdiff and the seqadjust hook to s32. Both are bounded by the 65535 byte packet limit, and the seqadj core is already s32 (nfctseqadjset() takes s32), so no previously accepted input is rejected.

BUG: KASAN: use-after-free in ctsipgetheader (net/netfilter/nfconntracksip.c:464) Read of size 1 at addr ffff888010800000 by task ksoftirqd/1/25 ctsipgetheader (net/netfilter/nfconntracksip.c:464) siphelptcp (net/netfilter/nfconntracksip.c:1694) nfconfirm (net/netfilter/nfconntrackproto.c:183) nfhookslow (net/netfilter/core.c:619) ip6output (net/ipv6/ip6output.c:246) ip6forward (net/ipv6/ip6output.c:690) ipv6rcv (net/ipv6/ip6input.c:351) netifreceiveskbonecore (net/core/dev.c:6212) processbacklog (net/core/dev.c:6676) napipoll (net/core/dev.c:7735) netrxaction (net/core/dev.c:7955) handlesoftirqs (kernel/softirq.c:622) runksoftirqd (kernel/softirq.c:1076) ...