CVE-2026-93196 in Linux
Summary
by MITRE • 09/17/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The Linux kernel vulnerability identified in the nvdimm subsystem specifically affects the virtio_pmem driver implementation. This flaw manifests as a slab-use-after-free condition triggered during interrupt handling within the virtualized persistent memory interface. The root cause lies in improper lifetime management of request structures associated with token-based operations. When a guest operating system submits a flush or similar operation to the host via the virtqueue, it retains ownership and reference counting for that specific request structure. However, under certain timing conditions involving interrupt processing on the host side, the driver incorrectly frees this data structure while it is still actively referenced by pending virtual queue operations. This creates a race condition where kernel memory previously allocated for one purpose is accessed after being returned to the free pool, leading to undefined behavior and potential system instability.
The technical mechanism of exploitation involves the interaction between virtio_pmem_flush() and the hardware interrupt handler. When flush requests are processed, the driver releases references prematurely before ensuring that all asynchronous operations dependent on those structures have completed. Specifically, the function __wake_up_common attempts to access memory associated with a request token that has already been deallocated by the submitter context. The KASAN report indicates an eight-byte read from address ffff88810fdcb710 within swapper/0, confirming that kernel code is dereferencing freed slab objects. This occurs because the virtqueue maintains visibility to these tokens even after submission, yet the driver fails to maintain sufficient reference counts to keep them alive until completion callbacks execute fully on both guest and host sides.
From an operational impact perspective, this vulnerability can lead to severe system crashes or kernel panics due to memory corruption. In virtualized environments using QEMU with PIIX chipsets as described in the trace, such errors may cause intermittent failures during persistent memory flush operations. Attackers who gain local access could potentially exploit these race conditions to trigger denial-of-service scenarios by repeatedly inducing use-after-free states. While direct code execution is less likely without additional primitives, the instability introduced compromises system reliability and data integrity for applications relying on durable storage semantics provided by nvdimm devices.
The resolution involves implementing proper reference counting mechanisms for struct virtio_pmem_request objects to ensure their lifetime extends appropriately across submission, queuing, and completion phases. The fix ensures that virtio_pmem_flush() holds a submitter reference while the request is pending in the virtqueue, which retains an additional reference once queued. Completion paths then correctly drop the virtqueue reference only after processing finishes, allowing the submitter to safely release its own reference before returning control flow. This approach aligns with standard memory safety practices required for concurrent kernel subsystems handling asynchronous I/O operations.
This vulnerability maps directly to CWE-416: Use After Free, which describes situations where a program uses a pointer that refers to freed memory. Additionally, the attack vector relates to ATT&CK technique T1059: Command and Scripting Interpreter if leveraged for denial-of-service through resource exhaustion or system instability in production environments. Mitigation strategies include applying kernel updates containing this patch immediately across all affected systems. Administrators should also monitor logs for KASAN reports indicating slab-use-after-free events, particularly those involving virtio_pmem_host_ack functions. Regular auditing of virtual machine configurations and ensuring up-to-date QEMU versions can further reduce exposure risks associated with these types of race conditions in persistent memory implementations.