CVE-2026-97996 in Linux
Summary
by MITRE • 09/25/2026
In the Linux kernel, the following vulnerability has been resolved:
virtio: fix use-after-free in unregister_virtio_device()
device_unregister() is device_del() plus put_device(). When the caller holds no extra reference, that drops the last one and runs the release callback, which for several transports frees the memory the embedded struct virtio_device sits in. unregister_virtio_device() then calls virtio_debug_device_exit(), which reads dev->debugfs_dir out of the freed object.
Affected transports are the ones whose release callback frees and whose remove path takes no reference: virtio_mmio, virtio_vdpa, virtio_uml, mlxbf-tmfifo and virtio_ccw. virtio_pci is unaffected because virtio_pci_remove() brackets the call with get_device() and put_device().
Remove the debugfs entries before the device can go away. They are only accessed through the protected debugfs interface, so debugfs_remove_recursive() waits for in-progress file operations before returning. Tearing them down while the device is still alive is therefore safe.
Reproduced on User-Mode Linux with CONFIG_KASAN and CONFIG_VIRTIO_DEBUG by unbinding a virtio-uml device:
BUG: KASAN: slab-use-after-free in virtio_debug_device_exit+0x36/0x4d Read of size 8 at addr 00000000616e0b10 by task init/1 __asan_report_load8_noabort virtio_debug_device_exit+0x36/0x4d unregister_virtio_device+0x48/0x75 virtio_uml_remove platform_remove device_release_driver_internal unbind_store
Freed by task 1: kfree virtio_uml_release_dev device_release kobject_put put_device device_unregister
With this applied, the report is gone and unbind is clean.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The Linux kernel vulnerability identified as a use-after-free flaw in the unregister_virtio_device function represents a critical memory safety issue within the virtio subsystem. This defect arises from an incorrect ordering of operations during device teardown sequences, specifically when drivers release their references to virtual devices without maintaining proper synchronization between resource deallocation and debug infrastructure cleanup. The core technical failure occurs because the standard kernel mechanism for unregistering devices involves calling device_unregister(), which internally executes device_del() followed by put_device(). When no additional reference is held by external entities or intermediate layers, this sequence triggers the release callback associated with the specific virtio transport driver. For several key transports including virtio_mmio, virtio_vdpa, virtio_uml, mlxbf-tmfifo, and virtio_ccw, these release callbacks are designed to free the memory containing the embedded struct virtio_device structure immediately upon invocation.
The vulnerability manifests when unregister_virtio_device() proceeds to invoke virtio_debug_device_exit() after the device has been unregistered but before ensuring that debugfs resources remain valid. Since the underlying memory for the virtio_device object may have already been freed by the transport-specific release callback, any subsequent access to fields within that structure constitutes a use-after-free condition. Specifically, the function attempts to read dev->debugfs_dir from an address space that has returned to the kernel slab allocator and potentially reallocated for other purposes. This leads to undefined behavior ranging from data corruption to potential privilege escalation if an attacker can influence what memory is allocated at that specific address before it is accessed again. The issue was successfully reproduced using User-Mode Linux with Kernel Address Sanitizer enabled, confirming a read of size eight bytes from a freed slab object during the unbinding process via platform_remove and device_release_driver_internal paths.
From a security classification perspective, this flaw aligns closely with CWE-416 Use After Free, which describes situations where software continues to use memory after it has been freed, leading to unpredictable execution flows. In terms of adversarial tactics, while direct exploitation requires precise timing and control over allocator behavior, the underlying mechanism relates to improper cleanup sequences that could be leveraged in conjunction with other vulnerabilities for arbitrary code execution or denial of service conditions under specific kernel configurations such as CONFIG_VIRTIO_DEBUG being enabled alongside KASAN instrumentation during testing. The affected transports lack protective measures like reference counting guards around their removal paths, unlike virtio_pci which remains unaffected because its remove function explicitly brackets the unregistration call with get_device() and put_device(), thereby preventing premature deallocation of the device structure until all dependent operations complete safely.
The operational impact of this vulnerability is significant for systems relying on affected virtualization transports, particularly in environments where dynamic binding and unbinding of virtio devices occur frequently or under load conditions that accelerate memory recycling cycles. An attacker with local access who can trigger driver removal events might exploit the race condition inherent in the use-after-free scenario to corrupt kernel heap structures, potentially gaining unauthorized read/write capabilities within the kernel space. Although exploitation complexity is high due to modern mitigations like KASLR and stack protectors, the presence of such flaws increases the attack surface for advanced persistent threats targeting virtualized infrastructure components. The vulnerability highlights risks associated with debug features that remain active in production kernels or those configured for extensive logging and tracing capabilities.
Mitigation strategies primarily involve applying upstream kernel patches that reorder the cleanup sequence to ensure safety before memory release occurs. The recommended fix involves removing debugfs entries prior to allowing the device structure to become eligible for deallocation by calling debugfs_remove_recursive() while the device is still alive and its reference count remains positive. This approach leverages the fact that debugfs operations are protected internally, ensuring that in-progress file accesses complete before removal proceeds, thus eliminating the window where freed memory could be accessed. Administrators should update their Linux kernels to versions containing this fix, particularly if they utilize any of the identified vulnerable transports such as virtio_uml or virtio_mmio. Additionally, disabling CONFIG_VIRTIO_DEBUG in production environments reduces exposure by removing the code path that triggers the vulnerability, although patching remains the definitive solution for long-term security posture improvement across all supported kernel versions affected by this defect.