CVE-2026-5165: 
Linux Red Hat vulnerability analysis and mitigation

CVE-2026-5165 is a use-after-free (expired pointer dereference) vulnerability in the VirtIO Block (BLK) device driver within the virtio-win package (kvm-guest-drivers-windows). When the VirtIO BLK device undergoes a reset, it fails to properly manage memory: pending SRBs (SCSI Request Blocks) are completed without fully resetting the device, leaving memory still in use by the device that Windows may subsequently free and reuse, resulting in memory corruption. Affected products include Red Hat virtio-win on Red Hat Enterprise Linux 9.0 and 10.0. The vulnerability was disclosed on March 30, 2026. It carries a CVSS v3.1 base score of 7.8 (High) per Red Hat's assessment, or 6.7 (Moderate) per the GitHub Advisory Database, depending on the privilege level assumed (Red Hat Advisory, Github Advisory).

The root cause is classified as CWE-825 (Expired Pointer Dereference) — the driver dereferences a pointer to memory that was previously valid but has since been freed and potentially reused by the Windows OS. During a VirtIO BLK device reset, the prior implementation only completed pending SRBs and continued without performing a full device reset and re-initialization sequence; as a result, the device could still complete requests referencing memory that Windows had already freed and reallocated, causing a use-after-free condition. The attack vector is local, requiring low-to-high privileges (depending on scoring authority), with low attack complexity and no user interaction required. The fix, implemented in GitHub pull request #1493, reimplements the bus reset operation with a proper 7-step sequence: pausing the adapter, resetting the VirtIO device, deleting queues, cleaning up device memory, completing pending SRBs, re-initializing the device, and resuming the adapter (Red Hat Bugzilla, GitHub PR #1493).

Successful exploitation allows a local attacker to corrupt system memory during a VirtIO BLK device reset event, potentially leading to system instability, crashes, or unexpected behavior. Given the high confidentiality, integrity, and availability impact scores, exploitation could result in disclosure of sensitive data, modification of memory contents, or denial of service (system crash/BSOD) within the affected Windows guest VM. The scope is limited to the affected guest VM and does not directly impact the hypervisor host, but memory corruption in a guest could be leveraged for further privilege escalation within that environment (Red Hat Advisory, Github Advisory).

1. Precondition: Attacker must have local access (low-to-high privilege) within a Windows guest VM running the vulnerable virtio-win VirtIO BLK driver on a KVM/QEMU hypervisor.
2. Trigger device reset: Initiate a VirtIO BLK device reset, for example by causing a device hang or issuing a bus reset command (e.g., via SRB_FUNCTION_RESET_BUS or SRB_FUNCTION_RESET_DEVICE) that causes the HwStorResetBus routine to be called.
3. Race condition exploitation: During the reset, the vulnerable driver completes pending SRBs without fully resetting the device. The device continues to use the associated memory buffers while Windows frees and reallocates them.
4. Memory corruption: When the device subsequently completes its in-flight requests and writes back to the now-freed/reallocated memory, a use-after-free condition occurs, corrupting heap memory in the Windows guest kernel.
5. Achieve objective: Depending on timing and memory layout, the attacker may leverage the corruption to cause a system crash (denial of service) or, with additional exploitation primitives, potentially escalate privileges within the guest VM (Red Hat Bugzilla, GitHub PR #1493).

• Logs: Unexpected Windows kernel crash dumps (BSOD/minidumps) referencing the viostor.sys driver or memory access violations during storage I/O operations.
• Process/System Behavior: Sudden system instability or blue screen errors (e.g., MEMORY_MANAGEMENT, KERNEL_DATA_INPAGE_ERROR, or PAGE_FAULT_IN_NONPAGED_AREA) in Windows guest VMs using VirtIO block storage.
• File System: Presence of crash dump files (MEMORY.DMP, minidump/*.dmp) in the Windows guest VM generated around the time of VirtIO BLK device reset events.
• Driver Traces: Debug trace output from viostor containing messages such as CompleteDpcRoutine RESET IN THE PROGRESS or unexpected re-entrancy in reset routines (visible if kernel debug logging is enabled) (Red Hat Bugzilla, GitHub PR #1493).

The fix is implemented in the kvm-guest-drivers-windows repository via pull request #1493 (merged February 2, 2026), which reimplements the VirtIO BLK bus reset operation with a proper full reset and re-initialization sequence. Users should update to a patched version of virtio-win that includes this fix; Red Hat has tracked this under their security advisory process for RHEL 9.0 and 10.0. As a workaround, limiting local access to guest VMs and avoiding conditions that trigger VirtIO BLK device resets (e.g., ensuring storage stability) can reduce exposure until a patched driver is deployed (GitHub PR #1493, Red Hat Advisory).

The vulnerability received standard automated coverage from vulnerability aggregators and CVE tracking services shortly after disclosure on March 30, 2026. No notable independent researcher commentary, vendor blog posts, or significant social media discussion beyond automated CVE broadcast accounts (e.g., Bluesky CVE feeds) has been identified. The fix was reviewed and merged by the virtio-win maintainers with constructive technical discussion on GitHub regarding reset sequencing and StorPort behavior (GitHub PR #1493).