The Linux Kernel, the operating system core itself.

Security Fix(es):

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

md/dm-raid: don't call mdreapsync_thread() directly

Currently mdreapsyncthread() is called from raidmessage() directly without holding 'reconfigmutex', this is definitely unsafe because mdreapsyncthread() can change many fields that is protected by 'reconfig_mutex'.

However, hold 'reconfigmutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozensync_thread() to fix deadlock").

Fix this problem by using stopsyncthread() to unregister sync_thread, like md/raid did.(CVE-2024-35808)

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

x86: fix user address masking non-canonical speculation issue

It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result:

CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“

Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window.

But that was true only up until Zen 5, which renames the AC bit [1]. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open.

Note that this affects not just the new address masking, but also the regular validuseraddress() check used by accessok(), and the asm version of the sign bit check in the getuser() helpers.

It does not affect putuser() or clearuser() variants, since there's no speculative result to be used in a gadget for those operations.(CVE-2024-50102)

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

genirq/msi: Store the IOMMU IOVA directly in msidesc instead of iommucookie

The IOMMU translation for MSI message addresses has been a 2-step process, separated in time:

1) iommudmaprepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated.

2) iommudmacomposemsimsg(): this cookie pointer is used to compute a translated message address.

This has an inherent lifetime problem for the pointer stored in the cookie that must remain valid between the two steps. However, there is no locking at the irq layer that helps protect the lifetime. Today, this works under the assumption that the iommu domain is not changed while MSI interrupts being programmed. This is true for normal DMA API users within the kernel, as the iommu domain is attached before the driver is probed and cannot be changed while a driver is attached.

Classic VFIO type1 also prevented changing the iommu domain while VFIO was running as it does not support changing the "container" after starting up.

However, iommufd has improved this so that the iommu domain can be changed during VFIO operation. This potentially allows userspace to directly race VFIODEVICEATTACHIOMMUFDPT (which calls iommuattachgroup()) and VFIODEVICESETIRQS (which calls into iommudmacomposemsi_msg()).

This potentially causes both the cookie pointer and the unlocked call to iommugetdomainfordev() on the MSI translation path to become UAFs.

Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVA address is already known during iommudmaprepare_msi() and cannot change. Thus, it can simply be stored as an integer in the MSI descriptor.

The other UAF related to iommugetdomainfordev() will be addressed in patch "iommu: Make iommudmaprepare_msi() into a generic operation" by using the IOMMU group mutex.(CVE-2025-38062)

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

Bluetooth: eir: Fix possible crashes on eircreateadv_data

eircreateadvdata may attempt to add EIRFLAGS and EIRTXPOWER without checking if that would fit.(CVE-2025-38303)

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

mm/vmalloc: fix data race in shownumainfo()

The following data-race was found in shownumainfo():

================================================================== BUG: KCSAN: data-race in vmallocinfoshow / vmallocinfoshow

read to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: shownumainfo mm/vmalloc.c:4936 [inline] vmallocinfoshow+0x5a8/0x7e0 mm/vmalloc.c:5016 seqreaditer+0x373/0xb40 fs/seqfile.c:230 procregreaditer+0x11e/0x170 fs/proc/inode.c:299 ....

write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: shownumainfo mm/vmalloc.c:4934 [inline] vmallocinfoshow+0x38f/0x7e0 mm/vmalloc.c:5016 seqreaditer+0x373/0xb40 fs/seqfile.c:230 procregreaditer+0x11e/0x170 fs/proc/inode.c:299 ....

value changed: 0x0000008f -> 0x00000000

According to this report,there is a read/write data-race because m->private is accessible to multiple CPUs. To fix this, instead of allocating the heap in procvmallocinit() and passing the heap address to m->private, vmallocinfoshow() should allocate the heap.(CVE-2025-38383)

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

drm/gem: Acquire references on GEM handles for framebuffers

A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below.

[ 156.791968] ------------[ cut here ]------------ [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dmabufvmap+0x224/0x430 [...] [ 156.942028] RIP: 0010:dmabufvmap+0x224/0x430 [ 157.043420] Call Trace: [ 157.045898] <TASK> [ 157.048030] ? showtraceloglvl+0x1af/0x2c0 [ 157.052436] ? showtraceloglvl+0x1af/0x2c0 [ 157.056836] ? showtraceloglvl+0x1af/0x2c0 [ 157.061253] ? drmgemshmemvmap+0x74/0x710 [ 157.065567] ? dmabufvmap+0x224/0x430 [ 157.069446] ? _warn.cold+0x58/0xe4 [ 157.073061] ? dmabufvmap+0x224/0x430 [ 157.077111] ? reportbug+0x1dd/0x390 [ 157.080842] ? handlebug+0x5e/0xa0 [ 157.084389] ? excinvalidop+0x14/0x50 [ 157.088291] ? asmexcinvalidop+0x16/0x20 [ 157.092548] ? dmabufvmap+0x224/0x430 [ 157.096663] ? dmaresvgetsingleton+0x6d/0x230 [ 157.101341] ? _pfxdmabufvmap+0x10/0x10 [ 157.105588] ? _pfxdmaresvgetsingleton+0x10/0x10 [ 157.110697] drmgemshmemvmap+0x74/0x710 [ 157.114866] drmgemvmap+0xa9/0x1b0 [ 157.118763] drmgemvmapunlocked+0x46/0xa0 [ 157.123086] drmgemfbvmap+0xab/0x300 [ 157.126979] drmatomichelperprepareplanes.part.0+0x487/0xb10 [ 157.133032] ? lockdepinitmaptype+0x19d/0x880 [ 157.137701] drmatomichelpercommit+0x13d/0x2e0 [ 157.142671] ? drmatomicnonblockingcommit+0xa0/0x180 [ 157.147988] drmmodeatomic_ioctl+0x766/0xe40 [...] [ 157.346424] ---[ end trace 0000000000000000 ]---

Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references.

Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before.

v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag(CVE-2025-38449)

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

s390/bpf: Fix bpfarchtextpoke() with newaddr == NULL again

Commit 7ded842b356d ("s390/bpf: Fix bpfplt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpfarchtextpoke() with newaddr == NULL"), causing intermittent kernel panics in e.g. perf's onswitch() prog to reappear.

Restore the fix and add a comment.(CVE-2025-38489)

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

iio: common: st_sensors: Fix use of uninitialize device structs

Throughout the various probe functions &indiodev->dev is used before it is initialized. This caused a kernel panic in stsensorspowerenable() when the call to devmregulatorbulkgetenable() fails and then calls deverrprobe() with the uninitialized device.

This seems to only cause a panic with deverrprobe(), deverr(), devwarn() and dev_info() don't seem to cause a panic, but are fixed as well.

The issue is reported and traced here: 1

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

iommu/amd: Avoid stack buffer overflow from kernel cmdline

While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length.(CVE-2025-38676)

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

netfilter: nf_tables: reject duplicate device on updates

A chain/flowtable update with duplicated devices in the same batch is possible. Unfortunately, netdev event path only removes the first device that is found, leaving unregistered the hook of the duplicated device.

Check if a duplicated device exists in the transaction batch, bail out with EEXIST in such case.

WARNING is hit when unregistering the hook:

[49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nfhookentryhead+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nfhookentryhead+0xaa/0x150(CVE-2025-38678)

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

fbdev: Fix vmalloc out-of-bounds write in fast_imageblit

This issue triggers when a userspace program does an ioctl FBIOPUT_CON2FBMAP by passing console number and frame buffer number. Ideally this maps console to frame buffer and updates the screen if console is visible.

As part of mapping it has to do resize of console according to frame buffer info. if this resize fails and returns from vcdoresize() and continues further. At this point console and new frame buffer are mapped and sets display vars. Despite failure still it continue to proceed updating the screen at later stages where vcdata is related to previous frame buffer and frame buffer info and display vars are mapped to new frame buffer and eventully leading to out-of-bounds write in fastimageblit(). This bheviour is excepted only when fgconsole is equal to requested console which is a visible console and updates screen with invalid struct references in fbconputcs().(CVE-2025-38685)

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

crypto: qat - flush misc workqueue during device shutdown

Repeated loading and unloading of a device specific QAT driver, for example qat4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded.

Since the driver uses a shared workqueue (qat_misc_wq) across all devices and owned by intel_qat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following:

BUG: unable to handle page fault for address: ffa000002e50a01c
#PF: supervisor read access in kernel mode
RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]
Call Trace:
  pm_bh_handler+0x1d2/0x250 [intel_qat]
  process_one_work+0x171/0x340
  worker_thread+0x277/0x3a0
  kthread+0xf0/0x120
  ret_from_fork+0x2d/0x50

To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded.

Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.(CVE-2025-39721)

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

rcu: Fix rcureadunlock() deadloop due to IRQ work

During rcureadunlockspecial(), if this happens during irqexit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up.

This is precisely what Xiongfeng found when invoking a BPF program on the tracetickstop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly.

irqexit() _irqexitrcu() /* inhardirq() returns false after this */ preemptcountsub(HARDIRQOFFSET) tickirqexit() ticknohzirqexit() ticknohzstopschedtick() tracetickstop() /* a bpf prog is hooked on this trace point */ _bpftracetickstop() bpftracerun2() rcureadunlockspecial() /* will send a IPI to itself */ irqworkqueueon(&rdp->deferqs_iw, rdp->cpu);

A simple reproducer can also be obtained by doing the following in tickirqexit(). It will hang on boot without the patch:

static inline void tickirqexit(void) { + rcureadlock(); + WRITEONCE(current->rcureadunlockspecial.b.needqs, true); + rcuread_unlock(); +

neeraj: Apply Frederic's suggested fix for PREEMPT_RT

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

rcu: Protect ->deferqsiw_pending from data race

On kernels built with CONFIGIRQWORK=y, when rcureadunlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcureadunlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.

In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally.

The per-CPU rcudata structure's ->deferqsiwpending field is updated by the irq-work handler and is both read and updated by rcureadunlock_special(). This resulted in the following KCSAN splat:

BUG: KCSAN: data-race in rcupreemptdeferredqshandler / rcureadunlock_special

read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcureadunlockspecial+0x175/0x260 _rcureadunlock+0x92/0xa0 rtspinunlock+0x9b/0xc0 _localbhenable+0x10d/0x170 _localbhenableip+0xfb/0x150 rcudobatch+0x595/0xc40 rcucpukthread+0x4e9/0x830 smpbootthreadfn+0x24d/0x3b0 kthread+0x3bd/0x410 retfromfork+0x35/0x40 retfromforkasm+0x1a/0x30

write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcupreemptdeferredqshandler+0x1e/0x30 irqworksingle+0xaf/0x160 runirqworkd+0x91/0xc0 smpbootthreadfn+0x24d/0x3b0 kthread+0x3bd/0x410 retfromfork+0x35/0x40 retfromfork_asm+0x1a/0x30

no locks held by irqwork/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finishtaskswitch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] _schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0

The problem is that irq-work handlers run with interrupts enabled, which means that rcupreemptdeferredqshandler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcureadunlockspecial(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->deferqsiwpending field.

This commit therefore disables interrupts across the portion of the rcupreemptdeferredqshandler() that updates the ->deferqsiw_pending field. This suffices because this handler is not a fast path.(CVE-2025-39749)

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

cifs: prevent NULL pointer dereference in UTF16 conversion

There can be a NULL pointer dereference bug here. NULL is passed to _cifssfumakenode without checks, which passes it unchecked to cifsstrnduptoutf16, which in turn passes it to cifslocaltoutf16_bytes where '*from' is dereferenced, causing a crash.

This patch adds a check for NULL 'src' in cifsstrndupto_utf16 and returns NULL early to prevent dereferencing NULL pointer.

Found by Linux Verification Center (linuxtesting.org) with SVACE(CVE-2025-39838)

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

mm: slub: avoid wake up kswapd in settrackprepare

settrackprepare() can incur lock recursion. The issue is that it is called from hrtimerstartrangens holding the percpu(hrtimerbases)[n].lock, but when enabled CONFIGDEBUGOBJECTSTIMERS, may wake up kswapd in settrackprepare, and try to hold the percpu(hrtimerbases)[n].lock.

Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain GFPKSWAPDRECLAIM in the debugobjectsfillpool() case. Inside stack depot they are processed by gfpnestedmask(). Since _slaballoc() has preemption disabled, we mask out _GFPDIRECT_RECLAIM from the flags there.

The oops looks something like:

BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .ownercpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spinbug+0x0 rawspinlockirqsave+0x80 hrtimertrytocancel+0x94 taskcontending+0x10c enqueuedlentity+0x2a4 dlserverstart+0x74 enqueuetaskfair+0x568 enqueuetask+0xac doactivatetask+0x14c ttwudoactivate+0xcc trytowakeup+0x6c8 defaultwakefunction+0x20 autoremovewakefunction+0x1c wakeup+0xac wakeupkswapd+0x19c wakeallkswapds+0x78 _allocpagesslowpath+0x1ac _allocpagesnoprof+0x298 stackdepotsaveflags+0x6b0 stackdepotsave+0x14 settrackprepare+0x5c _slaballoc+0xccc kmalloccachenoprof+0x470 _setpageowner+0x2bc postallochook[jt]+0x1b8 prepnewpage+0x28 getpagefromfreelist+0x1edc _allocpagesnoprof+0x13c allocslabpage+0x244 allocateslab+0x7c slaballoc+0x8e8 kmemcacheallocnoprof+0x450 debugobjectsfillpool+0x22c debugobjectactivate+0x40 enqueuehrtimer[jt]+0xdc hrtimerstartrangens+0x5f8 ...(CVE-2025-39843)

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

mm/vmalloc, mm/kasan: respect gfp mask in kasanpopulatevmalloc()

kasanpopulatevmalloc() and its helpers ignore the caller's gfpmask and always allocate memory using the hardcoded GFPKERNEL flag. This makes them inconsistent with vmalloc(), which was recently extended to support GFPNOFS and GFPNOIO allocations.

Page table allocations performed during shadow population also ignore the external gfpmask. To preserve the intended semantics of GFPNOFS and GFPNOIO, wrap the applytopagerange() calls into the appropriate memalloc scope.

xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.

There was a report here https://lkml.kernel.org/r/(CVE-2025-39910)

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

tcpbpf: Call skmsgfree() when tcpbpfsendverdict() fails to allocate psock->cork.

syzbot reported the splat below. [0]

The repro does the following:

1. Load a skmsg prog that calls bpfmsgcorkbytes(msg, cork_bytes)
2. Attach the prog to a SOCKMAP
3. Add a socket to the SOCKMAP
4. Activate fault injection
5. Send data less than cork_bytes

At 5., the data is carried over to the next sendmsg() as it is smaller than the corkbytes specified by bpfmsgcorkbytes().

Then, tcpbpfsendverdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + _GFP_NOWARN.

If the allocation fails, we need to revert the sk->skforwardalloc change done by skmsgalloc().

Let's call skmsgfree() when tcpbpfsend_verdict fails to allocate psock->cork.

The "copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "copied" to 0.

Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inetsockdestruct+0x623/0x730 net/ipv4/afinet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> _skdestruct+0x86/0x660 net/core/sock.c:2339 rcudobatch kernel/rcu/tree.c:2605 [inline] rcucore+0xca8/0x1770 kernel/rcu/tree.c:2861 handlesoftirqs+0x286/0x870 kernel/softirq.c:579 _dosoftirq kernel/softirq.c:613 [inline] invokesoftirq kernel/softirq.c:453 [inline] _irqexitrcu+0xca/0x1f0 kernel/softirq.c:680 irqexitrcu+0x9/0x30 kernel/softirq.c:696 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvecapictimerinterrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ>(CVE-2025-39913)

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

net/sched: schqfq: Fix null-deref in aggdequeue

To prevent a potential crash in aggdequeue (net/sched/schqfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c.

To avoid code duplication, the following changes are made:

1. Changed qdiscwarnnonwc(include/net/pkt_sched.h) into a static inline function.

2. Moved qdiscpeeklen from net/sched/schhfsc.c to include/net/pktsched.h so that sch_qfq can reuse it.

3. Applied qdiscpeeklen in agg_dequeue to avoid crashing.(CVE-2025-40083)

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

vfs: Don't leak disconnected dentries on umount

When user calls openbyhandleat() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfsdecodefhraw() will then try to connect this dentry to the dentry tree through reconnectpath(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookuponeunlocked() in reconnectone() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on danon") which removed adding of most disconnected dentries to sb->sanon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.(CVE-2025-40105)

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

x86/vmscape: Add conditional IBPB mitigation

VMSCAPE is a vulnerability that exploits insufficient branch predictor isolation between a guest and a userspace hypervisor (like QEMU). Existing mitigations already protect kernel/KVM from a malicious guest. Userspace can additionally be protected by flushing the branch predictors after a VMexit.

Since it is the userspace that consumes the poisoned branch predictors, conditionally issue an IBPB after a VMexit and before returning to userspace. Workloads that frequently switch between hypervisor and userspace will incur the most overhead from the new IBPB.

This new IBPB is not integrated with the existing IBPB sites. For instance, a task can use the existing speculation control prctl() to get an IBPB at context switch time. With this implementation, the IBPB is doubled up: one at context switch and another before running userspace.

The intent is to integrate and optimize these cases post-embargo.

dhansen: elaborate on suboptimal IBPB solution