Bug 2453015 (CVE-2026-5165)

Summary:	CVE-2026-5165 virtio-win: virtio-win: Memory corruption via use-after-free in VirtIO BLK device reset
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	Keywords:	Security
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in virtio-win, specifically within the VirtIO Block (BLK) device. When the device undergoes a reset, it fails to properly manage memory, resulting in a use-after-free vulnerability. This issue could allow a local attacker to corrupt system memory, potentially leading to system instability or unexpected behavior.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-03-30 14:47:30 UTC

The VirtIO BLK device does not have special reset events/routines
like the VirtIO SCSI device (controlq command VIRTIO_SCSI_T_TMF_LOGICAL_UNIT_RESET),
but Windows requires to have some mechanism to fix a device when it hangs.
The most appropriate way is perform a full VirtIO reset and initialization
flow based on spec.

The following flow is implemented:

Reset VirtIO device (virtio_device_reset)
Delete VirtIO queues (virtio_delete_queues)
Clean up all device memory (virtio_device_shutdown)
Complete all pending SRBs (in guest, CompletePendingRequestsOnReset)
Perform VirtIO device initialization (virtio_device_initialize, virtio_find_queues, etc)
Note: We don't pause StorPort because the port driver pauses all device IO queues for the
adapter and then calls the HwStorResetBus routine
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/storport/nc-storport-hw_reset_bus

Note: We cannot just complete all pending SRBs and continue, because this
memory will be still in use by the device and free in Windows. As a result,
we got use-after-free when the device completes the request and sends it back to Windows.
This may cause a memory corruption, as Windows may already have reused the memory.