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

wifi: cfg80211: check A-MSDU format more carefully

If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present.

bpf: Fix helper writes to read-only maps

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

KVM: x86/mmu: Check write tracking in all address spaces

kvmgfniswritetracked() checks only the supplied memslot, but page tracking is per-address-space and shadow pages are shared across all address spaces. With SMM, a GFN can therefore be write-tracked in one address space and appear untracked through the other.

Check the supplied slot first, then the slot for the other address space. This ensures all callers honor write tracking regardless of the active address space. In particular, it prevents mmutrytounsyncpages() from marking an upper-level shadow page unsync and eventually triggering the BUG in ptelistremove().

[invert direction of the conditional. - Paolo]

btrfs: fix transaction use-after-free in raid stripe insertion

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

net: bcmasp: clear txcb->last before writing each descriptor

bcmaspxmit() only wrote txcb->last = true for the final fragment of an SKB; non-final fragments left the field untouched. If a descriptor slot was reused while it still held a stale true from a previous SKB (possible when txspbringfull() underreported fullness), bcmasptxreclaim() would see last == true mid-SKB and call devconsumeskbany() prematurely, freeing the skbuff while its remaining fragments were still in flight.

Unconditionally clear txcb->last before the conditional set so every descriptor slot starts from a known false state regardless of what a prior transmission left behind.

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

wifi: mac80211: fix mbss changed flags corruption on 32 bit systems

On 32-bit systems, the size of an unsigned long is 4 bytes, while a u64 is 8 bytes. Therefore, when using oreachsetbit(bit, &bits, sizeof(changed) BITSPERBYTE), the code is incorrectly searching for a bit in a 32-bit variable that is expected to be 64 bits in size, leading to incorrect bit finding.

Solution: Ensure that the size of the bits variable is correctly adjusted for each architecture.

Call Trace: ? showregs+0x54/0x58 ? warn+0x6b/0xd4 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? reportbug+0x113/0x150 ? excoverflow+0x30/0x30 ? handlebug+0x27/0x44 ? excinvalidop+0x18/0x50 ? handleexception+0xf6/0xf6 ? excoverflow+0x30/0x30 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? excoverflow+0x30/0x30 ? ieee80211linkinfochangenotify+0xcc/0xd4 [mac80211] ? ieee80211meshwork+0xff/0x260 [mac80211] ? cfg80211wiphywork+0x72/0x98 [cfg80211] ? processonework+0xf1/0x1fc ? workerthread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? moddelayedworkon+0x4c/0x4c ? kthreadcompleteandexit+0x14/0x14 ? retfromfork+0x24/0x38 ? kthreadcompleteandexit+0x14/0x14 ? retfromforkasm+0xf/0x14 ? entryINT8032+0xf0/0xf0

[restore no-op path for no changes]

ALSA: seq: oss: Fix races at processing SysEx messages

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

sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket

BUG: KASAN: slab-use-after-free in tcpwritetimerhandler+0x156/0x3e0 Read of size 1 at addr ffff888111f322cd by task swapper/0/0

CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 Call Trace: <IRQ> dumpstacklvl+0x68/0xa0 printaddressdescription.constprop.0+0x2c/0x3d0 printreport+0xb4/0x270 kasanreport+0xbd/0xf0 tcpwritetimerhandler+0x156/0x3e0 tcpwritetimer+0x66/0x170 calltimerfn+0xfb/0x1d0 runtimers+0x3f8/0x480 runtimersoftirq+0x9b/0x100 handlesoftirqs+0x153/0x390 irqexitrcu+0x103/0x120 irqexitrcu+0xe/0x20 sysvecapictimerinterrupt+0x76/0x90 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x1a/0x20 RIP: 0010:defaultidle+0xf/0x20 Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242 RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000 R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 defaultidlecall+0x6b/0xa0 cpuidleidlecall+0x1af/0x1f0 doidle+0xbc/0x130 cpustartupentry+0x33/0x40 restinit+0x11f/0x210 startkernel+0x39a/0x420 x8664startreservations+0x18/0x30 x8664startkernel+0x97/0xa0 commonstartup64+0x13e/0x141 </TASK>

Allocated by task 595: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasanslaballoc+0x87/0x90 kmemcacheallocnoprof+0x12b/0x3f0 copynetns+0x94/0x380 createnewnamespaces+0x24c/0x500 unsharensproxynamespaces+0x75/0xf0 ksysunshare+0x24e/0x4f0 x64sysunshare+0x1f/0x30 dosyscall64+0x70/0x180 entrySYSCALL64afterhwframe+0x76/0x7e

Freed by task 100: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x54/0x70 kmemcachefree+0x156/0x5d0 cleanupnet+0x5d3/0x670 processonework+0x776/0xa90 workerthread+0x2e2/0x560 kthread+0x1a8/0x1f0 retfromfork+0x34/0x60 retfromforkasm+0x1a/0x30

Reproduction script:

mkdir -p /mnt/nfsshare mkdir -p /mnt/nfs/netns1 mkfs.ext4 /dev/sdb mount /dev/sdb /mnt/nfsshare systemctl restart nfs-server chmod 777 /mnt/nfsshare exportfs -i -o rw,norootsquash :/mnt/nfsshare

ip netns add netns1 ip link add name veth1peer type veth peer veth1 ifconfig veth1peer 11.11.0.254 up ip link set veth1 netns netns1 ip netns exec netns1 ifconfig veth1 11.11.0.1

ip netns exec netns1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP

(note: In my environment, a DESTROYCLIENTID operation is always sent immediately, breaking the nfs tcp connection.) ip netns exec netns1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns1

ip netns del netns1

The reason here is that the tcp socket in netns1 (nfs side) has been shutdown and closed (done in xsdestroy), but the FIN message (with ack) is discarded, and the nfsd side keeps sending retransmission messages. As a result, when the tcp sock in netns1 processes the received message, it sends the message (FIN message) in the sending queue, and the tcp timer is re-established. When the network namespace is deleted, the net structure accessed by tcp's timer handler function causes problems.

To fix this problem, let's hold netns refcnt for the tcp kernel socket as done in other modules. This is an ugly hack which can easily be backported to earlier kernels. A proper fix which cleans up the interfaces will follow, but may not be so easy to backport.

Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcommsockalloc()

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

staging: rtl8723bs: fix mismatched free of HalData in rtwsdioif1init()

padapter->HalData is allocated via vzalloc(), but incorrectly freed using kfree() in the rtwsdioif1init() error path. Using kfree() to release this vmalloc-backed buffer can lead to memory corruption.

Use rtwhaldatadeinit() to pair the free correctly and free HalData with vfree().

The bug was first flagged by an experimental static analysis tool we are developing for kernel memory-management bugs. Manual inspection confirms that the issue is still present in current mainline.

An x8664 allyesconfig build showed no new warnings. As we do not have suitable RTL8723BS SDIO hardware to test with, no runtime testing was able to be performed.

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

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

KVM: x86: Fix shadow paging use-after-free due to unexpected GFN

The shadow MMU computes GFNs for direct shadow pages using sp->gfn plus the SPTE index. This assumption breaks for shadow paging if the guest page tables are modified between VM entries (similar to commit aad885e77496, "KVM: x86/mmu: Drop/zap existing present SPTE even when creating an MMIO SPTE", 2026-03-27). The flow is as follows:

- a PDE is installed for a 2MB mapping, and a page in that area is accessed. KVM creates a kvmmmupage consisting of 512 4KB pages; the kvmmmupage is marked by FNAME(fetch) as direct-mapped because the guest's mapping is a huge page (and thus contiguous).

- the PDE mapping is changed from outside the guest.

- the guest accesses another page in the same 2MB area. KVM installs a new leaf SPTE and rmap entry; the SPTE uses the "correct" GFN (i.e. based on the new mapping, as changed in the previous step) but that GFN is outside of the [sp->gfn, sp->gfn + 511] range; therefore the rmap entry cannot be found and removed when the kvmmmupage is zapped.

- the memslot that covers the first 2MB mapping is deleted, and the kvmmmupage for the now-invalid GPA is zapped. However, rmapremove() only looks at the [sp->gfn, sp->gfn + 511] range established in step 1, and fails to find the rmap entry that was recorded by step 3.

- any operation that causes an rmap walk for the same page accessed by step 3 then walks a stale rmap and dereferences a freed kvmmmupage. This includes dirty logging or MMU notifier invalidations (e.g., from MADVDONTNEED).

The underlying issue is that KVM's walking of shadow PTEs assumes that if a SPTE is present when KVM wants to install a non-leaf SPTE, then the existing kvmmmupage must be for the correct gfn. Because the only way for the gfn to be wrong is if KVM messed up and failed to zap a SPTE... which shouldn't happen, but actually only happens in response to a guest write.

That bug dates back literally forever, as even the first version of KVM assumes that the GFN matches and walks into the "wrong" shadow page. However, that was only an imprecision until 2032a93d66fa ("KVM: MMU: Don't allocate gfns page for direct mmu pages") came along.

Fix it by checking for a target gfn mismatch and zapping the existing SPTE. That way the old SP and rmap entries are gone, KVM installs the rmap in the right location, and everyone is happy.

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

ipv6: mcast: extend RCU protection in igmp6send()

igmp6send() can be called without RTNL or RCU being held.

Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF.

Note that we no longer can use sockallocsendskb() because ipv6.igmpsk uses GFPKERNEL allocations which can sleep.

Instead use allocskb() and charge the net->ipv6.igmpsk socket under RCU protection.

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

eventpoll: don't decrement ep refcount while still holding the ep mutex

Jann Horn points out that epoll is decrementing the ep refcount and then doing a

mutexunlock(&ep->mtx);

afterwards. That's very wrong, because it can lead to a use-after-free.

That pattern is actually fine for the very last reference, because the code in question will delay the actual call to "epfree(ep)" until after it has unlocked the mutex.

But it's wrong for the much subtler "next to last" case when somebody else may also be dropping their reference and free the ep while we're still using the mutex.

Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion.

A mutex "unlock" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up.

See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics:

"mutexunlock() may access the mutex structure even after it has internally released the lock already - so it's not safe for another context to acquire the mutex and assume that the mutexunlock() context is not using the structure anymore"

So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops their reference and releases the 'ep' as it now has no users - all while the mutexunlock() is still accessing it.

Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole point of refcounts: unlike mutexes, they are inherently about object lifetimes).

bluetooth/l2cap: sync sock recv cb and release

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

net/smc: initialize closework early to avoid warning

We encountered a warning that closework was canceled before initialization.

WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 flushwork+0x19e/0x1b0 Workqueue: events smclgrterminatework [smc] RIP: 0010:flushwork+0x19e/0x1b0 Call Trace: ? wakeupcommon+0x7a/0x190 ? workbusy+0x80/0x80 cancelworktimer+0xe3/0x160 smcclosecancelwork+0x1a/0x70 [smc] smccloseactiveabort+0x207/0x360 [smc] smclgrterminate.part.38+0xc8/0x180 [smc] processonework+0x19e/0x340 workerthread+0x30/0x370 ? processonework+0x340/0x340 kthread+0x117/0x130 ? kthreadcancelwork+0x50/0x50 retfromfork+0x22/0x30

This is because when smcclosecancelwork is triggered, e.g. the RDMA driver is rmmod and the LGR is terminated, the conn->closework is flushed before initialization, resulting in WARNON(!work->func).

smclgrterminate | smcconnect{rdma|ism} ------------------------------------------------------------- | smcconncreate | \- smclgrregisterconn for conn in lgr->connsall | \- smcconnkill | \- smccloseactiveabort | \- smcclosecancelwork | \- cancelworksync | \- flushwork | (closework) | | smccloseinit | \- INITWORK(&closework)

So fix this by initializing closework before establishing the connection.

drm/amd/display: Skip on writeback when it's not applicable

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

uiohvgeneric: Don't free decrypted memory

In CoCo VMs it is possible for the untrusted host to cause setmemoryencrypted() or setmemorydecrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.

The VMBus device UIO driver could free decrypted/shared pages if setmemorydecrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.

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

Bluetooth: L2CAP: Fix possible crash on l2capecredconnrsp

If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2capchandel may invalidate the tmp cursor created by listforeachentrysafe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected.

Calling l2capchanclone directly may still lead to l2capchandel so instead schedule l2capchantimeout with delay 0 to close the channel asynchronously.

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

sctp: fix race between sctpwaitforconnect and peeloff

sctpwaitforconnect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTPSOCKOPTPEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctpwaitforconnect() returns success without noticing the migration — the caller then accesses the association under the wrong lock in sctpdatamsgfromuser().

Add the same sk != asoc->base.sk check that sctpwaitforsndbuf() already has, returning an error if the association was migrated while we slept.

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

vsock/virtio: bind uarg before filling zerocopy skb

virtiotransportsendpktinfo() allocates or reuses the zerocopy uarg before entering the send loop, but virtiotransportallocskb() still fills the skb before it inherits that uarg. When fixed-buffer vectored zerocopy hits MAXSKBFRAGS, iosgfromiter() may partially attach managed frags and return -EMSGSIZE. The rollback path call kfreeskb() to free an skb that carries SKBFLMANAGEDFRAGREFS but no uarg, so skbreleasedata() falls through to ordinary frag unref.

Pass the uarg into virtiotransportallocskb() and bind it immediately before virtiotransportfillskb(). This keeps control or no-payload skbs untouched while ensuring success and rollback share one lifetime rule.

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

wifi: iwlwifi: mei: pass correct argument to function

The first argument to iwlmeiwritecyclicbuf() should be the cldev but the qhead pointer is passed instead. Fix it.

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

netfilter: bridge: replace physindev with physinif in nfbridgeinfo

An skb can be added to a neigh->arpqueue while waiting for an arp reply. Where original skb's skb->dev can be different to neigh's neigh->dev. For instance in case of bridging dnated skb from one veth to another, the skb would be added to a neigh->arpqueue of the bridge.

As skb->dev can be reset back to nfbridge->physindev and used, and as there is no explicit mechanism that prevents this physindev from been freed under us (for instance neighflushdev doesn't cleanup skbs from different device's neigh queue) we can crash on e.g. this stack:

arpprocess neighupdate skb = skbdequeue(&neigh->arpqueue) neighresolveoutput(..., skb) ... brnfdevxmit brnfpreroutingfinishbridgeslow skb->dev = nfbridge->physindev brhandleframefinish

Let's use plain ifindex instead of netdevice link. To peek into the original netdevice we will use devgetbyindexrcu(). Thus either we get device and are safe to use it or we don't get it and drop skb.

ax25: Fix netdev refcount issue

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

smb3: missing lock when picking channel

Coverity spotted a place where we should have been holding the channel lock when accessing the ses channel index.

Addresses-Coverity: 1582039 ("Data race condition (MISSINGLOCK)")

btrfs: make sure that WRITTEN is set on all metadata blocks

f2fs: fix to truncate meta inode pages forcely

i40e: Do not allow untrusted VF to remove administratively set MAC

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

rds: tcp: Fix use-after-free of net in reqsktimerhandler().

syzkaller reported a warning of netns tracker [0] followed by KASAN splat [1] and another ref tracker warning [1].

syzkaller could not find a repro, but in the log, the only suspicious sequence was as follows:

18:26:22 executing program 1: r0 = socket$inet6mptcp(0xa, 0x1, 0x106) ... connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)

The notable thing here is 0x4001 in connect(), which is RDSTCPPORT.

So, the scenario would be:

1. unshare(CLONENEWNET) creates a per netns tcp listener in rdstcplisteninit(). 2. syz-executor connect()s to it and creates a reqsk. 3. syz-executor exit()s immediately. 4. netns is dismantled. [0] 5. reqsk timer is fired, and UAF happens while freeing reqsk. [1] 6. listener is freed after RCU grace period. [2]

Basically, reqsk assumes that the listener guarantees netns safety until all reqsk timers are expired by holding the listener's refcount. However, this was not the case for kernel sockets.

Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in inettwskpurge()") fixed this issue only for per-netns ehash.

Let's apply the same fix for the global ehash.

[0]: reftracker: net notrefcnt@0000000065449cc3 has 1/1 users at skalloc (./include/net/netnamespace.h:337 net/core/sock.c:2146) inet6create (net/ipv6/afinet6.c:192 net/ipv6/afinet6.c:119) sockcreate (net/socket.c:1572) rdstcplisteninit (net/rds/tcplisten.c:279) rdstcpinitnet (net/rds/tcp.c:577) opsinit (net/core/netnamespace.c:137) setupnet (net/core/netnamespace.c:340) copynetns (net/core/netnamespace.c:497) createnewnamespaces (kernel/nsproxy.c:110) unsharensproxynamespaces (kernel/nsproxy.c:228 (discriminator 4)) ksysunshare (kernel/fork.c:3429) x64sysunshare (kernel/fork.c:3496) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:129) ... WARNING: CPU: 0 PID: 27 at lib/reftracker.c:179 reftrackerdirexit (lib/reftracker.c:179)

[1]: BUG: KASAN: slab-use-after-free in inetcskreqskqueuedrop (./include/net/inethashtables.h:180 net/ipv4/inetconnectionsock.c:952 net/ipv4/inetconnectionsock.c:966) Read of size 8 at addr ffff88801b370400 by task swapper/0/0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:107 (discriminator 1)) printreport (mm/kasan/report.c:378 mm/kasan/report.c:488) kasanreport (mm/kasan/report.c:603) inetcskreqskqueuedrop (./include/net/inethashtables.h:180 net/ipv4/inetconnectionsock.c:952 net/ipv4/inetconnectionsock.c:966) reqsktimerhandler (net/ipv4/inetconnectionsock.c:979 net/ipv4/inetconnectionsock.c:1092) calltimerfn (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) runtimers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038) runtimersoftirq (kernel/time/timer.c:2053) dosoftirq (./arch/x86/include/asm/jumplabel.h:27 ./include/linux/jumplabel.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) irqexitrcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14)) </IRQ>

Allocated by task 258 on cpu 0 at 83.612050s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) kasanslaballoc (mm/kasan/common.c:343) kmemcachealloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867) copynetns (./include/linux/slab.h:701 net/core/netnamespace.c:421 net/core/netnamespace.c:480) createnewnamespaces (kernel/nsproxy.c:110) unsharensproxyname ---truncated---

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

KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation

Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01.

As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.