CVE-2026-98264

What it actually does

The flaw allows a virtio device to continue accessing vring memory after del_vqs releases it during virtsnd_remove or virtsnd_freeze, because the device is not reset first, resulting in a use-after-free in the ALSA virtio sound driver.

Why it matters to the business

Virtualized Linux systems relying on virtio audio may experience kernel crashes or memory corruption leading to denial of service or potential code execution in affected environments.

How an attack unfolds

An attacker with the ability to control or simulate a virtio-pci device can allow the device to remain active after vring backing memory is freed by triggering device removal or freeze paths after DRIVER_OK, enabling access to released memory regions.

How to fix it

Apply the upstream kernel fix that resets the device before deleting virtqueues in virtsnd_remove and virtsnd_freeze; rebuild and deploy updated kernels to affected systems.

How to confirm the fix worked

Inspect kernel source for the reordering change that calls reset prior to del_vqs in the ALSA virtio driver removal and freeze functions, and test device attach/detach cycles for stability.

Typical attack path

1. Achieve conditions for virtio sound device probe and successful DRIVER_OK initialization
2. Trigger virtsnd_remove or virtsnd_freeze paths
3. Exploit the window before device reset where the active device accesses now-freed vring memory

How to detect it

Review kernel logs and dmesg for crashes, warnings, or oops involving the virtio sound driver during device removal, suspend, or probe failure unwind paths.

What your security team should do

• Prioritize kernel updates containing the ALSA virtio reset ordering fix on systems using virtio sound
• Disable virtio sound devices where audio virtualization is not required
• Monitor kernel logs for virtio-related oops or warnings during device lifecycle events