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

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

ntfs: validate resident attribute lists and harden the validator

A base inode's $ATTRIBUTELIST is sanity-checked by loadattributelist() only on the non-resident path; ntfsreadlockedinode() copies a resident attribute list into ni->attrlist with a plain memcpy() and no validation at all. Every subsequent walk of ni->attrlist -- ntfsexternalattrfind(), ntfsinodeattachallextents() and ntfsattrlistneed() -- then trusts the entries are well-formed and reads attrlistentry fixed-header fields (lowestvcn at offset 8, mftreference at offset 16, and the name) with bounds that assume validation already happened. A crafted resident attribute list therefore reaches those walks unvalidated and can drive out-of-bounds reads of the attribute-list buffer.

loadattributelist() itself reads ale->nameoffset (offset 7), ale->mftreference (offset 16) and the name length under only an "al < alstart + size" bound, so its own validation loop can over-read the fixed header of a truncated trailing entry by a few bytes.

Factor the per-entry validation into ntfsattrlistentryisvalid(), which requires each entry's fixed header (offsetof(struct attrlistentry, name)) to be in range before any field is dereferenced, that ale->length is a multiple of 8 covering the fixed header plus the name, and that the entry is in use and carries a live MFT reference. ntfsattrlistisvalid() walks the buffer with it and checks the entries tile it exactly. Use the list validator in loadattributelist() (replacing the open-coded loop, closing its own over-read) and on the resident path in ntfsreadlockedinode() (which previously skipped validation entirely); patches 2/3 reuse the per-entry helper at the other two attribute-list walks.

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

perf tools: Use perfenvgetcputopology() in machineresolve()

machineresolve() accesses env->cpu[al->cpu].socketid after checking al->cpu >= 0 and env->cpu != NULL, but without validating al->cpu against env->nrcpusavail. Since al->cpu comes from the untrusted perf.data sample, a crafted file with a large CPU index causes an out-of-bounds heap read.

Use perfenvgetcputopology() which validates both NULL and bounds. Also bounds-check al->cpu before the cast to struct perfcpu (int16t): without this, values like 65536 silently truncate to 0, bypassing the accessor's internal check and returning CPU 0's topology.

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

netfilter: flowtable: avoid numencaps underflow on bridge VLAN untag

The DEVPATHBRVLANUNTAG case post-decrements info->numencaps inside WARNONONCE(). numencaps is u8, so if it's already 0 the decrement still happens and wraps it to 255. The break only leaves the inner switch -- a later path entry can set info->indev back to a real device, and we end up returning with numencaps == 255.

nftdevforwardpath() then walks info.encap[] (size 2) up to numencaps, which means an OOB stack read and a bogus count copied into the route descriptor.

Should only happen on a malformed bridge path stack, hence the WARN, but worth handling sanely. Move the decrement out of the WARN.

[ While at this, remove the WARNONONCE since this can only happen with a buggy bridge path stack --pablo ].

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

mptcp: options: reset DSS fields in case of unexpected size

A remote peer could send a malformed DSS with a wrong size, followed by another DSS or MPC + Data. In this case, the first suboption will be ignored, but leaving some fields written, which could lead to inconsistency or access uninitialized data.

Explicitly reset the fields that could have been modified in case of unexpected size.

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

mptcp: fastopen: only mark MPTFO subflows with SYN data

Passive TCP Fast Open accepts a valid-cookie SYN even when it carries no data. In that case the child socket's receive queue is intentionally left empty.

mptcpfastopensubflowsynacksetparams() set ismptfo before checking for queued SYN data. That made data-less TFO SYNs hit a WARN and, if the warning was non-fatal, left stale MPTFO state behind. The stale flag could later trigger a state-confusion bug in checkfullyestablished().

Only mark the subflow as MPTFO after confirming that an SKB was queued. Return quietly when the receive queue is empty.

Note that mptcpsubflowcontext's ismptfo field is now not just about subflows where the TFO was present, but about MPTFO subflow that consumed SYN data. Only having a valid cookie but not carrying data is not really "doing TFO".

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

libceph: fix multiple unsafe decodes in decodelocker()

decodelocker() in clslockclient.c contains three unsafe decode operations that allow a malicious or compromised OSD to trigger slab-out-of-bounds reads:

1. cephdecodecopy() at the lockeridt name field has no preceding bounds check. With p == end after cephstartdecoding() accepts structlen=0, this reads sizeof(cephentityname) = 9 bytes past the validated buffer boundary.

2. p += sizeof(struct cephtimespec) after the lockerinfot header is an unchecked pointer advance. A malicious OSD can position p past end, causing all subsequent safe checks to pass against a bogus boundary.

3. len = cephdecode32(p) has no preceding bounds check, and the immediately following p += len is uncapped. A malicious OSD can send len=0xffffffff, advancing p gigabytes past end and escaping the decode window entirely.

Fix all three by replacing bare operations with their safe variants: cephdecodecopy -> cephdecodecopysafe p += sizeof(...) -> cephdecodeskipn cephdecode32(p) -> cephdecode32safe p += len -> cephdecodeskipn

A new label is added to return -EINVAL on any bounds violation. -EINVAL is appropriate here: the data received from the OSD is structurally malformed, which is an invalid argument to the decode contract regardless of whether the caller or the wire is at fault.

Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment can trigger this against any kernel client that issues the lock.getinfo class method (e.g. during RBD exclusive lock acquisition) without any further privileges beyond OSD session establishment.

[ idryomov: use cephdecodeskipstring() to skip description, trim changelog ]

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

libceph: fix OOB read in decodewatchers() via missing bounds check

cephstartdecoding() validates that structlen bytes remain in the buffer after the encoding header, but accepts structlen=0 as valid: cephdecodeneed(p, end, 0, bad) always passes. When a malicious or compromised OSD sends an objlistwatchresponset reply with structlen=0, cephstartdecoding() returns success with p == end, leaving zero bytes guaranteed for subsequent reads.

The immediately following cephdecode32(p) in decodewatchers() has no preceding bounds check. With p == end this is a 4-byte read past the validated buffer boundary. The garbage value is then passed directly to kzallocobjs() as the watcher count.

The sibling function decodewatcher() already uses the safe variants (cephdecodecopysafe, cephdecode64safe, cephdecodeskip32) after its own cephstartdecoding() call. decodewatchers() is the only site that uses the bare variant, confirming an oversight.

Fix by replacing cephdecode32(p) with cephdecode32safe(p, end, numwatchers, bad), consistent with the established pattern.

Attacker model: a malicious or compromised OSD in a multi-tenant Ceph deployment (e.g. cloud) can trigger this against any kernel client that calls CEPHOSDOPLISTWATCHERS, without any further privileges beyond OSD session establishment.

[ idryomov: trim changelog ]

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

s390/vfioccw: Ensure first IDAW remains constant

The first IDAW in a list does not need to be on a 2K/4K boundary like all others, and so is read separately to accurately calculate the size of the buffer needed to read the full IDAL.

Verify that the address found in the first IDAW is unchanged between reads, to ensure a consistent set of IDAWs being worked with.

ceph: avoid fs reclaim while using current->journalinfo

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

riscv: lib: Fix ZBB strnlen reading past count boundary

The ZBB-optimized strnlen loop loads one word ahead before checking the aligned boundary:

REGL t1, SZREG(t0) // load next word addi t0, t0, SZREG // advance orc.b t1, t1 bgeu t0, t4, 4f // boundary check AFTER load

where t4 = (s + count) & -SZREG. When s is aligned and count is a multiple of SZREG, t4 equals s + count and the loop loads a full word starting at exactly s + count. If s + count falls on a page boundary with the next page unmapped, this faults.

Fix by computing the aligned boundary from the last valid byte (s + count - 1) instead of s + count. This makes the loop stop at the word containing the last valid byte rather than potentially loading the word after it. The count == 0 case is already handled by the beqz early exit.

Also add a pre-loop guard (bgeu t0, t4) for the case where all valid bytes fit within the first word. With the adjusted boundary, t4 can equal t0, and entering the loop with stale register state from the first-word processing would produce incorrect results.

The final minu clamp ensures the result is still correct when the last loaded word extends past s + count - 1 within the same aligned word.

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

ipvlan: inherit neededheadroom and neededtailroom from phydev

ipvlan devices inherit hardheaderlen from phydev during ipvlaninit(), but leave neededheadroom and neededtailroom set to 0.

When the underlying phydev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space.

This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when devhardheader() / ipvlanhardheader() prepends header data or when lower devices append tailroom.

Fix this by: 1. Inheriting neededheadroom and neededtailroom from phydev in ipvlaninit(). 2. Propagating neededheadroom and neededtailroom updates to attached ipvlans in ipvlandeviceevent() when receiving NETDEVFEATCHANGE events.

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

ovpn: skip rehash for peers already removed from byid

ovpnnlpeersetdoit() resolves the target peer via ovpnpeergetbyid() before taking ovpn->lock. In the window between the lookup (which only takes a refcount) and the subsequent spinlockbh(&ovpn->lock), a concurrent OVPNCMDPEERDEL, keepalive expiry, or socket teardown can take ovpn->lock first, run ovpnpeerremove() to unhash the peer from all four tables (byid, byvpnaddr4/6, bytranspaddr) and release the lock. setdoit then acquires ovpn->lock and calls ovpnpeerhashvpnip(), which re-inserts the now-removed peer back into the rehashing tables.

The same race affects the float path: ovpnpeerendpointsupdate() holds only a refcount and acquires ovpn->lock very late (after async AEAD decrypt and a netlink notification), then rehashes the peer in the bytranspaddr table.

The resurrected peer becomes reachable again from the RX lookup (ovpnpeergetbytranspaddr) and the TX VPN-IP lookup, even though userspace believes it is gone. Once the data-path refcount drops the peer is freed via callrcu while the hash entries embedded in it remain linked, opening a UAF window.

Bail out of the rehash when hashentryid is unhashed, mirroring the sentinel already used by ovpnpeerremove() to detect the already-removed state. The check is safe under ovpn->lock, which serializes every mutation of hashentryid, and is a no-op for the add path because ovpnpeeraddmp() inserts hashentryid before calling ovpnpeerhashvpnip().

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:

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:

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:

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:

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:

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

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:

net/smc: fix socket use-after-free during link group termination

smclgrterminate() drops connslock after finding a connection in lgr->connsall, but before taking a reference on its socket. The connection is embedded in the socket, and its registration reference protects it only while the connection remains in the tree.

A concurrent close can unregister the connection and drop that reference, freeing the socket before the termination worker reaches sockhold().

The race is reachable when close overlaps link group termination. Local stress testing reproduced the use-after-free and KASAN reported:

BUG: KASAN: slab-use-after-free in smclgrterminate.part.0 [smc] Write of size 4 by task kworker/3:3 Workqueue: events smclgrterminatework [smc] smclgrterminate.part.0 [smc]

The socket was allocated by smccreate(), freed through slabfreeafterrcudebug(), and was followed by:

refcountt: addition on 0; use-after-free. smclgrterminate.part.0 [smc]

Take the socket reference while connslock still protects the tree entry. The unregister path then cannot drop the last reference until termination has finished using the socket.

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

veth: convert fraglist skbs before running XDP

A fraglist skb can reach veth with datalen set but nrfrags zero. vethconvertskbtoxdpbuff() only converts skbs that are shared, locked, have frags[], or do not have enough headroom. It later uses skbisnonlinear() to decide whether to set XDPFLAGSHASFRAGS and xdpfragssize.

That exposes fraglist data to XDP as if it were stored in frags[], but frags[] is empty. AFXDP copy mode can then trust the bogus XDP fragment metadata, walk an empty fragment entry, and crash in memcpy() from xskrcv().

Route non-linear skbs through skbppcowdata() before exposing them to XDP, and only advertise XDP frags when the resulting skb has frags[]. skbcopybits() already handles fraglist input, and skbppcowdata() builds frags[] output with skbaddrxfrag(), which is the representation XDP multi-buffer expects.

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

rxrpc: Fix UAF in rxgkissuechallenge()

Fix rxgkissuechallenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.

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

rxrpc: Fix double unlock in rxrpcrecvmsg()

Fix a double unlock in rxrpcrecvmsg() when dealing with OOB messages.

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

afs: Fix netns teardown to cancel the preallocation charger

Fix the teardown of an afs network namespace to make sure it cancels the work item that keeps the preallocated rxrpc call/conn/peer queue charged before incoming calls are disabled (i.e. listen 0).

Also, if net->live is false because the afs netns is being deleted, make afschargepreallocation() skip charging and make afsrxnewcall() avoid requeuing the charger.

(This was found by AI review).

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

RDMA/srpt: fix integer overflow in immediate data length check

immbuf->len is a user-controlled uint32t received from the network. Adding it to immdataoffset without overflow checking allows a malicious initiator to send len=0xFFFFFFFF, causing reqsize to wrap around to a small value, bypassing the bounds check, and subsequently passing a ~4GB length to sginitone().

Use checkaddoverflow() to detect wrapping before the comparison.

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:

net/9p: fix race condition on rdma->state in transrdma.c

The rdma->state field is modified without holding reqlock in both recvdone() and p9cmeventhandler(), while rdmarequest() accesses the same field under the reqlock spinlock. This inconsistent locking creates a race condition:

- recvdone() running in softirq completion context sets rdma->state = P9RDMAFLUSHING without acquiring reqlock

- p9cmeventhandler() modifies rdma->state at multiple points (ADDRRESOLVED, ROUTERESOLVED, ESTABLISHED, CLOSED) without reqlock

- rdmarequest() uses spinlockirqsave(&rdma->reqlock, flags) to protect the read-modify-write of rdma->state

The race can cause lost state transitions: recvdone() or the CM event handler could set state to FLUSHING/CLOSED while rdmarequest() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown.

Fix by adding reqlock protection to all rdma->state modifications in recvdone() and p9cmeventhandler(), matching the pattern already used in rdmarequest(). Use spinlockirqsave/spinunlockirqrestore in the CM event handler since it can race with recvdone() which runs in softirq context.

Tested with a kernel module that races two threads (simulating rdmarequest and recvdone/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions.

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

xprtrdma: Fix bcall rep leak and unbounded peek

rpcrdmaisbcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue.

First, the speculative peek

p = xdrinlinedecode(xdr, 0); / five p++ reads follow /

asks xdrinlinedecode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify the reply as a backchannel call.

Second, after the post-peek

p = xdrinlinedecode(xdr, 3 sizeof(p)); if (unlikely(!p)) return true;

the short-header arm returns true without calling rpcrdmabcreceivecall(). The contract with the caller is that a true return transfers ownership of rep to the backchannel path:

rpcrdmareplyhandler() if (rpcrdmaisbcall(rxprt, rep)) return; / bare return, skips outpost / ... outpost: rpcrdmapostrecvs(rxprt, credits + ...);

Because rpcrdmabcreceivecall() never ran, no one took rep, but rpcrdmareplyhandler still bare-returns past rpcrdmarepput() and rpcrdmapostrecvs(). The rep, with its persistently DMA-mapped receive buffer, is orphaned on rballreps and freed only at transport teardown. This completion reposts nothing, so its slot is reclaimed only when a later forward-channel reply reaches outpost and rpcrdmapostrecvs() allocates a fresh rep to backfill; absent that traffic the Receive queue drains and the peer's Sends draw RNR NAKs.

Fix by consulting xdr->end after the zero-length peek so the five be32 reads cannot run unless 20 bytes of wire payload remain. A byte-precise comparison against xdr->end is required because a non-4-aligned receive rounds the stream's word count up past the true payload. Also return false from the short-header arm so the reply falls through the normal outnorqst cleanup chain (rpcrdmarepput() plus rpcrdmapostrecvs()).