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

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>

9p/net: fix improper handling of bogus negative read/write replies

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.

ceph: avoid fs reclaim while using current->journalinfo

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

smb: client: fix double-free in SMB2ioctl() replay

A response-bearing attempt can return a replayable error and free its response buffer. If SMB2ioctlinit() fails before the next send, cleanup retains the previous buffer type and frees that response again.

Reset response bookkeeping before each attempt to prevent the stale free.

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

ksmbd: run set info with opener credentials

SMB2 SETINFO handlers call path-based VFS helpers after checking the access mask granted to the SMB handle. Those helpers perform their owner, inode permission and LSM checks using the current ksmbd worker credentials.

Run the complete SETINFO dispatch with the credentials captured when the handle was opened. This also removes the separate security information credential setup and keeps all SETINFO classes under one credential scope.

Direct overridecreds() is used because it can nest with the request credential overrides already used by rename and link helpers.

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

netfilter: flowtable: IPIP tunnel hardware offload is not yet support

No driver supports for IPIP tunnels yet, give up early on setting up the hardware offload for this scenario.

This patch adds a stub that can be enhanced to add more configuration that are currently not supported. As of now, the offload work is enqueued to the worker, then ignored if the hardware offload configuration is not supported.

Check the NFFLOWHW flag to know if this entry was already tried once to be offloaded so this is not retried on refresh when unsupported. Move NFFLOWHW flag check to nfflowoffloadadd(). If this NFFLOWHW flag is unset the del and stats variants are never called.

This can be updated later on to skip hardware offload work to be queued in case hardware offload does not support it.

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:

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:

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:

netfs: Fix early put of sink folio in netfsreadgaps()

Fix netfsreadgaps() to release the sink page it uses after waiting for the request to complete. The way the sink page is used is that an ITERBVEC-class iterator is created that has the gaps from the target folio at either end, but has the sink page tiled over the middle so that a single read op can fill in both gaps.

The bug was found by KASAN detecting a UAF on the generic/075 xfstest in the cifsd kernel thread that handles reception of data from the TCP socket:

BUG: KASAN: use-after-free in copytoiter+0x48a/0xa20 Write of size 885 at addr ffff888107f92000 by task cifsd/1285 CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy) Call Trace: dumpstacklvl+0x5d/0x80 printreport+0x17f/0x4f1 kasanreport+0x100/0x1e0 kasancheckrange+0x10f/0x1e0 asanmemcpy+0x3c/0x60 copytoiter+0x48a/0xa20 skbdatagramiter+0x2c9/0x430 skbcopydatagramiter+0x6e/0x160 tcprecvmsglocked+0xce0/0x1130 tcprecvmsg+0xeb/0x300 inetrecvmsg+0xcf/0x3a0 sockrecvmsg+0xea/0x100 cifsreadvfromsocket+0x3a6/0x4d0 [cifs] cifsreaditerfromsocket+0xdd/0x130 [cifs] cifsreadvreceive+0xaad/0xb10 [cifs] cifsdemultiplexthread+0x1148/0x1740 [cifs] kthread+0x1cf/0x210

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

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

scsi: lpfc: Fix buffer free/clear order in deferred receive path

Fix a use-after-free window by correcting the buffer release sequence in the deferred receive path. The code freed the RQ buffer first and only then cleared the context pointer under the lock. Concurrent paths (e.g., ABTS and the repost path) also inspect and release the same pointer under the lock, so the old order could lead to double-free/UAF.

Note that the repost path already uses the correct pattern: detach the pointer under the lock, then free it after dropping the lock. The deferred path should do the same.

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:

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.

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:

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:

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:

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>