CVE-2026-46146

What it actually does

This vulnerability is a denial-of-service flaw in the Linux kernel ALSA USB audio driver. The affected code path, convert_chmap_v3(), processes USB audio channel map descriptors and advances through descriptor data using the descriptor length field, cs_desc->wLength. Because the driver did not sufficiently validate that length before using it as the loop increment, a malformed USB audio descriptor with an invalid or zero length can cause the kernel to enter an endless loop while parsing the device descriptor. Successful exploitation can consume CPU, hang the affected kernel path, and degrade or halt system availability. The issue does not provide confidentiality or integrity impact and is not known to enable code execution or privilege escalation.

Why it matters to the business

An attacker with local access, or the ability to introduce a malicious or malformed USB audio device to a system, could cause affected Linux systems to become unstable or unavailable. This is most relevant for workstations, kiosks, embedded Linux devices, operational technology endpoints, and servers where USB ports are accessible or where USB device redirection is permitted. Because the issue affects kernel-level USB audio handling, exploitation may require a reboot or device removal to restore normal operation. The currently provided EPSS score is low and the issue is not listed in CISA KEV, so broad internet-scale exploitation is unlikely; however, the operational impact can still be meaningful in environments with exposed physical ports or untrusted USB peripherals.

How an attack unfolds

An attacker prepares a USB device, USB emulator, or USB redirection payload that presents itself as a USB audio device with a malformed class-specific audio descriptor. When the vulnerable Linux system enumerates the device and the snd-usb-audio driver parses the channel map descriptor, the malformed wLength value causes convert_chmap_v3() to loop without making progress. The loop can tie up kernel execution, causing high CPU usage, hung tasks, watchdog warnings, loss of responsiveness, or a system-level denial of service. Exploitation requires local interaction with the USB subsystem or equivalent access to present a malicious USB audio device; there is no indication from the supplied data that this is remotely exploitable over the network.

How to fix it

Upgrade to a Linux kernel version that includes the upstream ALSA usb-audio fix validating cs_desc->wLength in convert_chmap_v3(). No exact fixed package versions were provided in the input, so use the security advisories and fixed kernel builds from the relevant Linux distribution, appliance vendor, or embedded platform maintainer. Where immediate patching is not possible, reduce exposure by blocking untrusted USB devices, disabling unused USB ports, enforcing USB device allowlisting, and preventing automatic use of untrusted USB audio devices. If USB audio is not required, consider disabling the snd-usb-audio kernel module through distribution-supported module blacklist controls and unloading it where operationally safe. For high-risk systems, combine patching with physical port control, BIOS/UEFI USB restrictions where appropriate, USBGuard-style policy enforcement, and monitoring for unexpected USB audio device enumeration.

How to confirm the fix worked

Confirm that systems are running a kernel package or vendor firmware release that contains the ALSA usb-audio descriptor length validation fix. Review distribution changelogs, kernel package advisories, or vendor release notes for references to the ALSA usb-audio convert_chmap_v3() fix. Validate exposure by checking whether the snd-usb-audio module is present or loaded and whether USB audio devices are permitted by policy. On Linux systems, administrators can review loaded modules, kernel versions, and USB device policy using standard OS tooling such as uname, package manager queries, lsmod, modinfo, dmesg, journalctl, lsusb, and USB allowlisting configuration. In test environments only, use a controlled malformed USB descriptor test case or vendor-provided regression test to confirm the patched kernel rejects the malformed descriptor rather than looping. Do not test malformed USB devices on production systems because validation attempts may intentionally trigger denial of service on vulnerable hosts.

Typical attack path

1. Obtain local physical access to the target system, access to a connected USB-over-IP path, or another mechanism for presenting a USB device to the host.
2. Prepare a malicious USB audio device or emulated USB gadget that exposes a malformed USB audio channel map descriptor.
3. Connect or expose the device to the vulnerable Linux system.
4. Allow the kernel USB subsystem to enumerate the device and load or invoke the snd-usb-audio driver.
5. Trigger descriptor parsing in the ALSA USB audio code path.
6. Cause convert_chmap_v3() to enter an endless loop due to the malformed descriptor length value.
7. Result in degraded availability, CPU exhaustion, kernel watchdog events, system unresponsiveness, or a required reboot.

How to detect it

Post-exploitation detection should focus on evidence of suspicious USB audio device enumeration followed by kernel availability symptoms. Review kernel logs from dmesg, journalctl, syslog, audit logs, endpoint telemetry, and device-control platforms for newly attached USB audio-class devices, loading of the snd-usb-audio driver, repeated USB descriptor parsing errors, watchdog soft lockups, RCU stalls, hung task messages, high CPU in kernel context, or unexpected reboots shortly after USB insertion. Correlate these events with physical access logs, USB device-control alerts, hypervisor or VDI USB redirection events, and asset management records. If a system became unresponsive, collect persistent journal logs, crash dumps if configured, pstore/ramoops records, kernel panic data, and any available USB device metadata such as vendor ID, product ID, serial number, device class, and connection timestamp. The presence of snd-usb-audio or USB audio activity alone is not proof of exploitation; the strongest signal is a temporal sequence of unexpected USB audio enumeration followed by kernel stalls, watchdog alerts, or system hang. No public threat actors or ransomware campaigns were provided for this vulnerability, and there are no known unique network indicators because the attack is local to USB/device presentation.

• convert_chmap_v3
• snd_usb_audio
• snd-usb-audio
• usb-audio
• watchdog: BUG: soft lockup
• INFO: rcu_sched detected stalls
• INFO: rcu_preempt detected stalls
• INFO: task
• blocked for more than
• New USB device found
• USB Audio

What your security team should do

• Prioritize patching systems where USB ports are physically accessible, USB device redirection is enabled, or untrusted users can attach peripherals.
• Obtain fixed kernel builds from the relevant Linux distribution or device vendor and deploy them through normal kernel update processes.
• Where USB audio is not needed, disable or blacklist the snd-usb-audio module as a compensating control until patching is complete.
• Implement USB device control policies that allow only approved device classes and approved device identifiers on sensitive Linux endpoints.
• Review kiosk, lab, manufacturing, point-of-sale, embedded, and shared-workstation environments for exposed USB ports and weak physical controls.
• Monitor kernel logs for USB audio enumeration followed by soft lockups, RCU stalls, hung tasks, or unexpected reboots.
• Treat unexpected USB audio devices on servers or controlled endpoints as suspicious and investigate the source of the device connection.
• Because this issue is not in KEV and has low EPSS, prioritize based on local exposure rather than internet-facing risk.