Description

In the Linux kernel, the following vulnerability has been resolved: virtio-fs: avoid double-free on failed queue setup virtio_fs_setup_vqs() allocates fs->vqs and fs->mq_map before calling virtio_find_vqs(). If virtio_find_vqs() fails, the error path frees both pointers and returns an error to virtio_fs_probe(). virtio_fs_probe() then drops the last kobject reference, and virtio_fs_ktype_release() frees fs->vqs and fs->mq_map again. This leaves dangling pointers in struct virtio_fs and can trigger a double-free during probe failure cleanup. Set fs->vqs and fs->mq_map to NULL immediately after kfree() in the virtio_fs_setup_vqs() error path so that the later kobject release sees an uninitialized state and kfree(NULL) becomes harmless. This can be reproduced when a broken virtio-fs device advertises more request queues than the transport actually provides. In that case virtio_find_vqs() fails while setting up the extra queue, and the probe path reaches the double-free cleanup sequence.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-09-24T17:17:16.410Z",
  "pubdate": "2026-09-24T17:17:16.410Z",
  "executiveSummary": "This vulnerability is a memory management flaw identified within the Linux kernel virtio-fs driver, specifically relating to the handling of virtqueue (vq) setup failures.\nThe vulnerability is classified as a double-free condition occurring during the probe phase of a virtio-fs device.\nThe flaw affects the virtio_fs_setup_vqs() function, which fails to properly nullify pointers upon encountering an error during the virtio_find_vqs() initialization.\nAn attacker capable of simulating or triggering a malformed virtio-fs device that advertises an excessive number of request queues can induce this race condition or cleanup failure.\nThe impact includes potential kernel memory corruption, system instability, or a kernel panic, leading to a Denial of Service (DoS) condition.\nSuccessful exploitation requires the ability to influence the virtio-fs device configuration, typically through compromised or malicious hardware/virtual hardware emulation layers.",
  "technicalDetails": "The root cause of this vulnerability lies in an inconsistent error handling path within the virtio-fs driver. During the device initialization sequence, virtio_fs_setup_vqs() performs heap allocations for 'fs->vqs' and 'fs->mq_map'. If the subsequent call to virtio_find_vqs() fails—often due to a discrepancy between advertised request queues and transport capabilities—the driver enters an error recovery routine.\nIn the existing implementation, the error path within virtio_fs_setup_vqs() executes kfree() on these pointers but fails to update the reference pointers in the 'struct virtio_fs' structure to NULL. Consequently, these pointers remain as dangling references.\nFollowing the failed setup, the driver control flow returns to virtio_fs_probe(). In the event of a probe failure, the kernel triggers the cleanup sequence, which eventually calls the release function virtio_fs_ktype_release(). This release function performs an additional kfree() on 'fs->vqs' and 'fs->mq_map' based on the assumption that they are still valid, unreleased memory blocks.\nBecause the pointers were not nullified in the previous error path, the kernel attempts to free the same memory addresses a second time. In the Linux kernel's memory allocator, a double-free of an active object can corrupt the slab allocator metadata. This corruption frequently leads to system-wide instability, including kernel panics (oops), arbitrary memory overwrites, or the potential for advanced memory corruption-based exploitation.\nThe attack flow requires a device that triggers the failure condition: an inflated queue count within the virtio configuration space. Once the driver attempts to map these virtual queues and hits the failed state, the double-free is guaranteed to occur during the subsequent kobject cleanup. This does not strictly require external network exposure, but rather interaction with the virtio hardware backend or a virtualized environment facilitating malicious virtio-fs device communication."
}