Cloudanix VulnDB

CVE-2026-93196

High · 8.4

CVSS

8.4

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

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

  1. Obtain local code execution on a Linux guest or host using virtio_pmem
  2. Trigger repeated virtio_pmem_flush operations to queue and complete requests
  3. Race the submitter's free with the host_ack completion path
  4. 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