CVE-2026-46018

What it actually does

This is a local availability vulnerability in the Linux kernel ALSA USB audio driver. When the kernel parses USB Audio Class 2 sample-rate range data from a malformed USB audio device, it stops adding rates after the configured maximum but, in vulnerable versions, continues processing additional malformed triplets. That can repeatedly emit the kernel log message "invalid uac2 rates" while the driver probe path still holds a registration mutex, causing kernel log flooding, device-probe delays, audio subsystem disruption, and potentially broader local denial of service through CPU, I/O, or log-storage pressure. The flaw does not provide confidentiality or integrity impact and is not known to enable privilege escalation.

Why it matters to the business

Systems that allow local users or physical actors to attach USB devices, or that pass USB devices into virtualized workloads, can be disrupted by a malicious or malformed USB audio device. The most likely business impact is workstation, kiosk, embedded-device, or server instability where USB peripherals are accepted, with possible loss of audio functionality, degraded system responsiveness, or log storage exhaustion. The EPSS score is very low and this issue is not in CISA KEV, so broad internet-scale exploitation is unlikely; risk is highest in environments with untrusted physical access, shared labs, manufacturing floors, conference rooms, help desks, or USB passthrough.

How an attack unfolds

An attacker needs local capability to introduce a malicious USB Audio Class 2 device, emulate one through a USB gadget-capable system, or influence USB passthrough to a vulnerable Linux host. The device presents malformed UAC2 sample-rate range data containing more entries than the ALSA parser is designed to collect. During device probe, the vulnerable kernel module parses the response, reaches MAX_NR_RATES, but continues iterating over remaining triplets instead of stopping completely. Each malformed continuation can trigger repeated "invalid uac2 rates" kernel messages while the driver holds register_mutex. By supplying many malformed entries or repeatedly reconnecting the device, the attacker can cause log flooding, slow or blocked audio registration, resource consumption, and local denial of service.

How to fix it

Update the Linux kernel to a vendor-supported release that includes the ALSA usb-audio fix for stopping UAC2 sample-rate parsing once MAX_NR_RATES is reached. No exact fixed version was provided in the input, so use the affected distribution’s security advisory or upstream stable kernel changelog to identify the first fixed package for each deployed kernel stream. Where immediate patching is not possible, reduce exposure by blocking untrusted USB peripherals, disabling USB passthrough from untrusted sources, restricting physical access, using USB device-control policies, and, if operationally acceptable, preventing the snd-usb-audio module from loading on systems that do not require USB audio. Module blacklisting may break legitimate USB audio devices and should be tested before broad deployment.

How to confirm the fix worked

Confirm remediation by verifying that running kernel packages include the vendor patch for the ALSA usb-audio UAC2 range parsing issue, then reboot into the fixed kernel where required. Validate the active kernel with standard host inventory commands such as uname -a and package-manager queries, and compare against the distribution advisory. On systems where USB audio is not required and mitigation is used, confirm that snd-usb-audio is not loaded and cannot be auto-loaded. Review kernel logs after attaching known-good USB audio devices to ensure normal probing works and that repeated "invalid uac2 rates" messages are no longer produced. For high-assurance validation, test in a controlled lab with a malformed UAC2 device or emulator and verify that parsing stops without excessive logging or prolonged probe blocking.

Typical attack path

1. Gain local physical access to a vulnerable Linux system, or access to a path that can present USB devices to it, such as USB passthrough, a docking station, or an emulated USB gadget.
2. Prepare a malicious or malformed USB Audio Class 2 device that returns excessive or invalid sample-rate range triplets.
3. Connect or present the device to the target so the Linux kernel loads/probes the snd-usb-audio driver.
4. Trigger parsing of the malformed UAC2 RANGE response during ALSA USB audio device initialization.
5. Cause the vulnerable parser to continue processing beyond MAX_NR_RATES, repeatedly logging "invalid uac2 rates" while holding the audio registration mutex.
6. Maintain or repeat the condition to degrade availability through log flooding, device-probe stalls, audio disruption, or resource exhaustion.

How to detect it

Look for evidence in kernel, system, and audit logs that a USB audio device triggered repeated ALSA parsing errors. Primary sources include dmesg, journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, endpoint telemetry for USB insertion events, and EDR device-control logs. Search for bursts of "invalid uac2 rates" near USB enumeration messages, snd-usb-audio module load events, or repeated USB connect/disconnect activity. Correlate timestamps with physical access records, user sessions, virtualization USB passthrough events, and unusual growth of kernel log files. Indicators of likely exploitation include high-frequency repetition of the error string, log-volume spikes, audio-device probe failures, kernel threads spending excessive time during USB device probing, or unexpected USB audio devices appearing on systems that normally do not use them. There are no network indicators because exploitation is local through USB device presentation.

• invalid uac2 rates
• snd-usb-audio
• usb-audio
• USB Audio Class 2
• UAC2
• new high-speed USB device
• New USB device found
• usbcore: registered new interface driver snd-usb-audio

What your security team should do

• Prioritize patching Linux endpoints, kiosks, embedded systems, and servers where untrusted users can physically attach USB devices or where USB passthrough is enabled.
• Inventory systems with the snd-usb-audio module loaded or USB audio support enabled, and focus remediation on those assets first.
• Apply vendor kernel updates and reboot into the fixed kernel; do not rely on package installation alone if the old kernel remains running.
• Where patching is delayed, enforce USB device-control policies that allow only approved peripherals and block unknown USB audio devices.
• Disable or blacklist snd-usb-audio on systems that do not require USB audio, after confirming there is no operational dependency.
• Monitor kernel logs for repeated "invalid uac2 rates" messages, especially around USB device insertion events.
• Investigate repeated USB connect/disconnect activity combined with kernel log flooding as potential attempted exploitation or malicious peripheral testing.
• For virtualized or lab environments, restrict USB passthrough to trusted devices and administrators.
• Because EPSS is low and there is no KEV listing, treat this as targeted/local-risk remediation rather than emergency internet-exposed remediation unless the environment has high untrusted physical-access exposure.