CVE-2026-43436

What it actually does

This is a Linux kernel denial-of-service flaw in the ALSA USB-audio driver’s Scarlett2 mixer quirk handling. When parsing a malformed USB audio interface descriptor, the driver assumes an endpoint exists and may dereference a NULL pointer in the Scarlett2 interface parsing path. A local attacker with the ability to present or cause parsing of a crafted USB audio device descriptor can trigger a kernel oops or panic, resulting in loss of system availability. The issue does not provide confidentiality or integrity impact based on the available information.

Why it matters to the business

Successful exploitation can crash affected Linux systems that load the vulnerable USB-audio code path, causing service interruption, workstation instability, or downtime for systems that allow USB device attachment or USB passthrough. The business risk is highest for shared workstations, kiosks, audio-production systems, test labs, virtualization hosts with USB passthrough, and environments where untrusted users can connect USB devices. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a very low EPSS score, so urgency is primarily driven by local exposure and operational criticality rather than known widespread exploitation.

How an attack unfolds

An attacker obtains local access to an affected Linux system or a path to make the system parse attacker-controlled USB descriptors, such as attaching a malicious USB device, using a programmable USB gadget, or abusing USB passthrough in a virtualized environment. The crafted device presents malformed USB audio descriptors that reach the ALSA usb-audio Scarlett2 mixer parsing logic. During parsing, the vulnerable kernel code assumes an interface has at least one endpoint and accesses endpoint data without first validating the endpoint count. If the malformed descriptor omits the expected endpoint, the kernel hits a NULL pointer dereference. Depending on kernel configuration and error handling, this can produce a kernel oops, hang, or panic, disrupting availability until the system or affected service is recovered.

How to fix it

Upgrade affected Linux kernels to a vendor-supported release that includes the ALSA usb-audio fix adding endpoint-count validation for Scarlett2 mixer interface parsing. Because no exact fixed package versions were provided, use the fixed kernel versions published by the relevant Linux distribution or kernel vendor advisory. Prioritize systems where untrusted users can attach USB devices, where USB passthrough is enabled, or where audio devices are frequently connected. If immediate patching is not possible, reduce exposure by disabling or restricting USB device attachment, disabling USB passthrough for untrusted guests, applying USB device allowlisting, blocking untrusted USB audio devices, or preventing automatic loading of the vulnerable usb-audio path where operationally acceptable. Kernel module blacklisting of USB audio functionality may mitigate exposure but can break legitimate audio workflows and should be tested before deployment.

How to confirm the fix worked

Confirm the system is running a patched vendor kernel that contains the Scarlett2 usb-audio endpoint-count sanity check. Validate package state using the distribution’s package manager and compare the installed kernel version against the vendor advisory for this issue. Reboot into the patched kernel after installation; merely installing a kernel package is insufficient if the host continues running an older kernel. Check whether the snd-usb-audio module is loaded or available, and identify systems with USB audio usage or USB passthrough enabled. For exposure validation, review whether untrusted local users can attach USB devices or configure USB passthrough. In a controlled test environment only, attach known-good USB audio devices to confirm expected functionality after patching; do not use untrusted malformed descriptors on production systems.

Typical attack path

1. Gain local physical access, local user access, or access to a USB passthrough/control path on an affected Linux system.
2. Present a crafted USB audio device descriptor intended to trigger the Scarlett2 mixer quirk parsing path in the ALSA usb-audio driver.
3. Ensure the parsed interface descriptor is malformed and lacks the endpoint expected by the vulnerable code.
4. Cause the kernel to load or interact with the USB audio device so descriptor parsing occurs.
5. Trigger a NULL pointer dereference in the Scarlett2 interface parsing logic.
6. Crash, hang, or destabilize the affected system, causing denial of service.

How to detect it

To determine whether this was already exploited or accidentally triggered, review kernel and system logs around crashes, reboots, USB device insertion events, and audio-device enumeration. Relevant sources include journald, dmesg, syslog, kern.log, audit logs for local device activity, endpoint management logs, USB device-control tooling, hypervisor logs for USB passthrough events, and crash dump artifacts such as kdump, vmcore, or kernel oops reports. Look for a sequence where a USB audio device is connected, the snd-usb-audio driver initializes, Scarlett2 or Focusrite-related mixer parsing appears, and the system records a NULL pointer dereference, kernel oops, panic, or unexpected reboot. If crash dumps are available, inspect stack traces for ALSA usb-audio and Scarlett2 parsing functions, especially scarlett2_find_fc_interface. Because exploitation relies on malformed USB descriptors, there may be no network indicator; investigation should focus on local device attachment, USB enumeration history, physical access, and USB passthrough control-plane records.

• BUG: kernel NULL pointer dereference
• NULL pointer dereference
• kernel NULL pointer dereference
• Oops:
• Kernel panic
• snd-usb-audio
• usb-audio
• ALSA: usb-audio
• scarlett2_find_fc_interface
• Scarlett2
• Focusrite Scarlett
• bNumEndpoints
• new high-speed USB device
• new full-speed USB device
• USB disconnect
• /var/log/kern.log
• /var/log/syslog
• /var/crash
• /proc/vmcore

What your security team should do

• Inventory Linux systems that permit physical USB access, USB audio devices, or USB passthrough, and prioritize them for kernel updates.
• Patch affected systems using the appropriate vendor kernel update and reboot into the fixed kernel.
• For high-risk endpoints, enforce USB device control policies such as allowlisting, blocking unknown USB audio devices, or disabling unused USB ports.
• Review virtualization platforms and desktop infrastructure for USB passthrough exposure to untrusted users or guests.
• Monitor kernel logs for USB audio driver crashes, NULL pointer dereferences, oopses, or panics referencing Scarlett2 or ALSA usb-audio parsing.
• Where patching is delayed, consider temporarily disabling snd-usb-audio or USB audio device support if business operations allow.
• Because there is no known KEV listing, ransomware association, or mature public exploit indicated, treat this as a targeted local availability risk rather than an internet-scale emergency.