CVE-2026-64490

What it actually does

This flaw affects the Linux kernel virtio sound (ALSA virtio-snd) driver. The driver trusts control metadata supplied by a virtio sound device, including the control type and value count. If a buggy or malicious device advertises an invalid control type or an excessively large value count, the kernel can index outside expected arrays or copy more data than fixed-size ALSA control structures can safely hold. The likely outcomes are kernel memory corruption, out-of-bounds read/write behavior, kernel crash, information disclosure, or potentially code execution in kernel context depending on exploitability and platform hardening.

Why it matters to the business

Systems using Linux guests or workloads with virtio sound enabled may be exposed to a high-impact kernel-level flaw. Successful exploitation can crash affected systems, compromise confidentiality and integrity of the guest operating system, or support broader compromise from a malicious or compromised virtualization layer. The risk is highest for virtual machines, sandboxes, desktop virtualization, CI environments, or cloud/edge platforms where virtio-snd devices are attached. Although public exploit maturity is currently reported as none and EPSS is low, the CVSS impact is high because exploitation occurs in kernel code and can affect the whole operating system.

How an attack unfolds

An attacker needs control over, or the ability to emulate, a virtio sound device presented to a vulnerable Linux kernel. This could occur through a malicious hypervisor/device model, a compromised host providing virtual devices to guests, a hostile local virtualization setup, or another path that lets an attacker attach or manipulate a virtio-snd device. The malicious device returns crafted control metadata with an unsupported control type or an oversized value count. The vulnerable kernel driver parses that metadata and exposes the control through ALSA. When ALSA control information, get, or put operations are performed, the driver uses the untrusted metadata to index type-mapping arrays and size loops or memcpy operations against fixed-size structures. This can trigger out-of-bounds memory access in kernel space, leading to a crash or potentially further kernel compromise.

How to fix it

Apply the Linux kernel update from the relevant distribution or kernel vendor that includes validation of virtio-snd control type and value count in virtsnd_kctl_parse_cfg(). No exact fixed package versions were provided in the input, so use vendor advisories and changelogs for the deployed distribution or kernel branch. As a mitigation where patching is not immediately possible, disable virtio sound for systems that do not require it, remove virtual sound devices from VM definitions, avoid exposing virtio-snd to untrusted guests or hosts, and consider blacklisting the virtio_snd kernel module where operationally safe. Harden virtualization management access so untrusted users cannot attach or modify virtual audio devices.

How to confirm the fix worked

Confirm that affected systems are running a kernel build containing the virtio-snd control metadata validation fix. Review kernel package changelogs, vendor advisory references, or source patches for changes in the ALSA virtio-snd control handling path, especially validation in virtsnd_kctl_parse_cfg(). Check whether virtio sound support is present or loaded using kernel configuration and module inventory, such as CONFIG_SND_VIRTIO and the virtio_snd module. Validate exposure by reviewing VM definitions or hypervisor configurations for attached virtio sound devices. After remediation, confirm that systems boot the updated kernel, the previous vulnerable kernel is not selected by default, and virtio-snd functionality, if required, continues to operate without kernel warnings, oopses, or ALSA control errors.

Typical attack path

1. Identify a Linux system running a kernel with the vulnerable ALSA virtio sound driver enabled.
2. Gain control of a virtio sound device endpoint, such as through a malicious or compromised hypervisor, emulator, host device model, or local virtual-machine configuration path.
3. Expose a crafted virtio-snd device to the vulnerable kernel.
4. Return malicious control metadata, such as an invalid control type or an excessive control value count.
5. Trigger ALSA control enumeration or control get/put operations from the guest.
6. Cause the kernel driver to perform out-of-bounds array access or oversized memory copy operations.
7. Leverage the resulting memory corruption for denial of service, information disclosure, or potential kernel-level execution.

How to detect it

There are no widely known public exploit indicators in the provided data, so detection should focus on exposure plus signs of attempted kernel memory corruption. Collect and review kernel logs, system journal entries, hypervisor or emulator logs, VM configuration history, and crash dumps. Look for kernel oops, panic, KASAN, UBSAN, page fault, general protection fault, or slab corruption messages that reference virtio_snd, virtio_kctl, virtsnd_kctl_info, virtsnd_kctl_get, virtsnd_kctl_put, virtsnd_kctl_parse_cfg, ALSA control handling, or snd_ctl paths. Investigate unexpected addition of virtio sound devices to VMs, especially near the time of kernel crashes. On systems using kernel crash dumping, inspect vmcore data for stack traces in sound/virtio/virtio_kctl.c or ALSA control IOCTL paths. Review virtualization management audit logs for unauthorized VM hardware changes, new audio devices, or emulator command-line changes adding virtio sound support.

• virtio_snd
• virtio-snd
• CONFIG_SND_VIRTIO
• virtsnd_kctl_info
• virtsnd_kctl_get
• virtsnd_kctl_put
• virtsnd_kctl_parse_cfg
• sound/virtio/virtio_kctl.c
• g_v2a_type_map
• ALSA: virtio
• snd_ctl_elem_value
• virtio_snd_ctl_value
• BUG: kernel NULL pointer dereference
• BUG: unable to handle page fault
• general protection fault
• kernel BUG at sound/virtio/virtio_kctl.c
• KASAN: out-of-bounds
• KASAN: slab-out-of-bounds
• UBSAN: array-index-out-of-bounds
• kernel panic
• Oops:
• modprobe virtio_snd
• virtio-sound-pci
• -device virtio-sound

What your security team should do

• Prioritize patching Linux systems that run as virtual machines or sandboxes with virtio sound enabled, especially where the virtualization host, emulator, or device model is less trusted.
• Inventory systems for virtio sound exposure by checking loaded modules, kernel configuration, and VM device definitions.
• Disable or remove virtio-snd devices from workloads that do not need virtual audio.
• Restrict access to virtualization management interfaces that can attach or modify virtual sound devices.
• Monitor kernel logs for crashes, warnings, or oops traces involving virtio_snd, virtio_kctl, ALSA control handling, or snd_ctl paths.
• Treat unexpected kernel oopses in virtio_snd control functions as potential exploitation attempts and preserve memory, kernel logs, VM configuration, and hypervisor logs for investigation.
• Track distribution advisories for exact fixed kernel package versions and ensure vulnerable kernels are removed or deprioritized in bootloader configuration after upgrade.