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]
ALSA: seq: oss: Fix races at processing SysEx messages
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.
bluetooth/l2cap: sync sock recv cb and release
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:
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.
A flaw was found within the parsing of extended attributes in the kernel ksmbd module. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this to disclose sensitive information on affected installations of Linux. Only systems with ksmbd enabled are vulnerable to this CVE.
A use-after-free flaw was found in btsdioremove in drivers\bluetooth\btsdio.c in the Linux Kernel. A call to btsdioremove with an unfinished job may cause a race problem which leads to a UAF on hdev devices.
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)")
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.
Bluetooth: l2cap: Add missing chan lock in l2capecredreconfrsp
dma-buf: heaps: Fix off-by-one in CMA heap fault handler
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans
During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix out of bounds reads when finding clock sources
The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads.
For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop.
For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check.
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices
A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usbgetconfiguration for allocating dev->config.
This can lead to out-of-bounds accesses later, e.g. in usbdestroyconfiguration.
afunix: Don't leave consecutive consumed OOB skbs.
In the Linux kernel, the following vulnerability has been resolved:
posix-cpu-timers: fix race between handleposixcputimers() and posixcputimerdel()
If an exiting non-autoreaping task has already passed exitnotify() and calls handleposixcputimers() from IRQ, it can be reaped by its parent or debugger right after unlocktasksighand().
If a concurrent posixcputimerdel() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cputimertaskrcu() and/or locktasksighand() will fail.
Add the tsk->exitstate check into runposixcputimers() to fix this.
This fix is not needed if CONFIGPOSIXCPUTIMERSTASKWORK=y, because exittaskwork() is called before exitnotify(). But the check still makes sense, taskworkadd(&tsk->posixcputimerswork.work) will fail anyway in this case.
In the Linux kernel, the following vulnerability has been resolved:
xfrm: interface: fix use-after-free after changing collectmd xfrm interface
collectmd property on xfrm interfaces can only be set on device creation, thus xfrmichangelink() should fail when called on such interfaces.
The check to enforce this was done only in the case where the xi was returned from xfrmilocate() which doesn't look for the collectmd interface, and thus the validation was never reached.
Calling changelink would thus errornously place the special interface xi in the xfrminet->xfrmi hash, but since it also exists in the xfrminet->collectmdxfrmi pointer it would lead to a double free when the net namespace was taken down [1].
Change the check to use the xi from netdevpriv which is available earlier in the function to prevent changes in xfrm collectmd interfaces.
[1] resulting oops: [ 8.516540] kernel BUG at net/core/dev.c:12029! [ 8.516552] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 8.516559] CPU: 0 UID: 0 PID: 12 Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary) [ 8.516565] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 8.516569] Workqueue: netns cleanupnet [ 8.516579] RIP: 0010:unregisternetdevicemanynotify+0x101/0xab0 [ 8.516590] Code: 90 0f 0b 90 48 8b b0 78 01 00 00 48 8b 90 80 01 00 00 48 89 56 08 48 89 32 4c 89 80 78 01 00 00 48 89 b8 80 01 00 00 eb ac 90 <0f> 0b 48 8b 45 00 4c 8d a0 88 fe ff ff 48 39 c5 74 5c 41 80 bc 24 [ 8.516593] RSP: 0018:ffffa93b8006bd30 EFLAGS: 00010206 [ 8.516598] RAX: ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60 [ 8.516601] RDX: 0000000000000004 RSI: 0000000000000000 RDI: dead000000000122 [ 8.516603] RBP: ffffa93b8006bdd8 R08: dead000000000100 R09: ffff98fe4133c100 [ 8.516605] R10: 0000000000000000 R11: 00000000000003d2 R12: ffffa93b8006be00 [ 8.516608] R13: ffffffff96c1a510 R14: ffffffff96c1a510 R15: ffffa93b8006be00 [ 8.516615] FS: 0000000000000000(0000) GS:ffff98fee73b7000(0000) knlGS:0000000000000000 [ 8.516619] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.516622] CR2: 00007fcd2abd0700 CR3: 000000003aa40000 CR4: 0000000000752ef0 [ 8.516625] PKRU: 55555554 [ 8.516627] Call Trace: [ 8.516632] <TASK> [ 8.516635] ? rtnlislocked+0x15/0x20 [ 8.516641] ? unregisternetdevicequeue+0x29/0xf0 [ 8.516650] opsundolist+0x1f2/0x220 [ 8.516659] cleanupnet+0x1ad/0x2e0 [ 8.516664] processonework+0x160/0x380 [ 8.516673] workerthread+0x2aa/0x3c0 [ 8.516679] ? pfxworkerthread+0x10/0x10 [ 8.516686] kthread+0xfb/0x200 [ 8.516690] ? pfxkthread+0x10/0x10 [ 8.516693] ? pfxkthread+0x10/0x10 [ 8.516697] retfromfork+0x82/0xf0 [ 8.516705] ? pfxkthread+0x10/0x10 [ 8.516709] retfromforkasm+0x1a/0x30 [ 8.516718] </TASK>
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix possible UAF in ip6finishoutput2()
If skbexpandhead() returns NULL, skb has been freed and associated dst/idev could also have been freed.
We need to hold rcureadlock() to make sure the dst and associated idev are alive.
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mana: Validate rxhashkeylen
Sashiko points out that rxhashkeylen comes from a uAPI structure and is blindly passed to memcpy, allowing the userspace to trash kernel memory. Bounds check it so the memcpy cannot overflow.