CVE-2026-93196
High · 8.4CVSS
8.4
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A bug in how Linux handles certain virtual memory devices could let a local user crash the system or gain higher privileges, so update the operating system kernel when the fix is available.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Moderate
- Impact
- Full Compromise
- Component
- OS kernel
- Class
- Use After Free
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Use-after-free in virtio_pmem request handling: virtio_pmem_host_ack wakes a struct virtio_pmem_request that the submitter has already freed after the token remains reachable on the virtqueue, causing slab corruption in __wake_up_common.
Why it matters to the business
Kernel crashes or memory corruption on affected Linux systems using virtio_pmem devices, potentially leading to denial of service or local privilege escalation in virtualized environments; low exploitability reduces immediate risk but still requires prompt patching on high-value hosts.
How an attack unfolds
An attacker with local access crafts a sequence of virtio_pmem flush operations that race the request submitter's free against the virtqueue completion path; the freed request is later woken, triggering the use-after-free.
How to fix it
Update the Linux kernel to a version containing the refcount fix for struct virtio_pmem_request; ensure both the submitter reference and virtqueue reference are properly dropped.
How to confirm the fix worked
Boot a patched kernel and confirm absence of KASAN reports during virtio_pmem stress tests; verify the refcount increments and decrements appear in the virtio_pmem_flush and completion paths via code review or ftrace.
Typical attack path
- Obtain local code execution on a Linux guest or host using virtio_pmem
- Trigger repeated virtio_pmem_flush operations to queue and complete requests
- Race the submitter's free with the host_ack completion path
- Trigger __wake_up on the dangling request token to corrupt kernel memory
How to detect it
Search kernel logs for KASAN slab-use-after-free reports mentioning __wake_up_common and virtio_pmem_host_ack; inspect crash dumps for dangling virtio_pmem_request objects referenced after free.
What your security team should do
- Prioritize kernel updates on systems exposing virtio_pmem devices within 30 days
- Monitor for KASAN or slab corruption logs involving __wake_up_common and virtio_pmem
- Limit untrusted local access on virtualized hosts using persistent memory backends until patched
The record
In the Linux kernel, the following vulnerability has been resolved: nvdimm: virtio_pmem: refcount requests for token lifetime KASAN reports slab-use-after-free in __wake_up_common(): BUG: KASAN: slab-use-after-free in __wake_up_common+0x114/0x160 Read of size 8 at addr ffff88810fdcb710 by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-next-20260220-00006-g1eae5f204ec3 #4 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x6d/0xb0 print_report+0x170/0x4e2 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? __virt_addr_valid+0x1dc/0x380 kasan_report+0xbc/0xf0 ? __wake_up_common+0x114/0x160 ? __wake_up_common+0x114/0x160 __wake_up_common+0x114/0x160 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 __wake_up+0x36/0x60 virtio_pmem_host_ack+0x11d/0x3b0 ? sched_balance_domains+0x29f/0xb00 ? __pfx_virtio_pmem_host_ack+0x10/0x10 ? _raw_spin_lock_irqsave+0x98/0x100 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 vring_interrupt+0x1c9/0x5e0 ? __pfx_vp_interrupt+0x10/0x10 vp_vring_interrupt+0x87/0x100 ? __pfx_vp_interrupt+0x10/0x10 __handle_irq_event_percpu+0x17f/0x550 ? __pfx__raw_spin_lock+0x10/0x10 handle_irq_event+0xab/0x1c0 handle_fasteoi_irq+0x276/0xae0 __common_interrupt+0x65/0x130 common_interrupt+0x78/0xa0 </IRQ> virtio_pmem_host_ack() wakes a request that has already been freed by the submitter. This happens when the request token is still reachable via the virtqueue, but virtio_pmem_flush() returns and frees it. Fix the token lifetime by refcounting struct virtio_pmem_request. virtio_pmem_flush() holds a submitter reference, and the virtqueue holds an extra reference once the request is queued. The completion path drops the virtqueue reference, and the submitter drops its reference before returning.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|