Cloudanix VulnDB

CVE-2026-31778

High · 7.1

CVSS

7.1

EPSS

0.1%

Published

May 1, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A specially crafted USB audio device can make some Linux systems crash or expose sensitive system memory when it is plugged in.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

This is an off-by-one memory-safety flaw in the Linux kernel ALSA caiaq USB audio driver. During device initialization, the driver builds a whitespace-stripped card identifier in a 16-byte stack buffer but allows 16 bytes of data to be written without reserving space for the terminating null byte. The unterminated stack string is then passed into ALSA card ID handling, where the kernel scans beyond the end of the local buffer. A crafted USB device name, especially one containing many non-ASCII, non-space characters such as multibyte UTF-8 sequences, can trigger a stack out-of-bounds read. The most likely consequences are kernel memory disclosure to adjacent code paths or a kernel crash/panic, resulting in denial of service. The issue has existed in the affected driver code since Linux 2.6.31-rc1-era changes introduced in 2009.

Why it matters to the business

Successful exploitation requires local access or the ability to present a malicious USB audio device to a Linux system, so broad internet-scale exploitation is unlikely. However, affected endpoints, workstations, kiosks, recording systems, lab systems, or servers with accessible USB ports could crash or expose kernel stack memory when a malicious or compromised USB audio device is connected. Operational impact is highest where physical USB access is realistic, where untrusted peripherals are used, or where Linux systems must remain continuously available. The CVSS score is high because the flaw can affect confidentiality and availability, but EPSS is very low, exploitation maturity is currently reported as none, and it is not listed in CISA KEV, so remediation should be prioritized based on physical-access exposure and kernel patching cadence rather than emergency internet-facing risk.

How an attack unfolds

An attacker needs a path to connect or emulate a USB device that is handled by the ALSA caiaq USB audio driver. The attacker crafts the device descriptors so the product or short name contains enough non-space, non-ASCII characters to fill the driver's 16-byte local ID buffer without leaving room for a null terminator. When the Linux kernel initializes the USB audio device, the caiaq driver strips whitespace and copies the resulting identifier into the stack buffer using the incorrect boundary check. Because the string is not null-terminated, subsequent ALSA card ID processing continues reading beyond the stack buffer until it encounters a terminating byte or invalid character. On hardened or instrumented kernels this can produce a KASAN stack-out-of-bounds report; on production systems it may lead to a kernel crash or potentially expose adjacent stack contents through error paths or internal state. There is no indication of public weaponized exploitation or named threat actor activity for this CVE at this time.

How to fix it

Update the Linux kernel to a vendor-supported version that includes the ALSA caiaq fix changing the copy bound to reserve space for the null terminator. No exact fixed package versions were provided in the input, so use the fixed kernel packages published by the relevant Linux distribution or apply the upstream patch that changes the loop bound from the full destination size to one byte less than the destination size. Where immediate patching is not possible, reduce exposure by disabling or blocking the affected caiaq USB audio driver if it is not required, restricting physical USB access, disabling unused USB ports in firmware or operating system policy, using USB device-control allowlisting, and preventing untrusted USB peripherals from being connected. Kernel live patching may not be sufficient unless the specific affected driver code path is covered by the vendor's live patch; verify with the kernel vendor.

How to confirm the fix worked

Confirm remediation by checking that systems are running a kernel build from the distribution or vendor that contains the ALSA caiaq off-by-one fix. Review kernel changelogs or source packaging for references to the caiaq init_card fix, snd_usb_caiaq, or reserving one byte for the card ID null terminator. If source validation is required, verify that the whitespace-stripping loop bounds the copy to one less than the destination buffer size. On running systems, identify whether the affected module is present or loaded by checking for snd_usb_caiaq in loaded kernel modules and module directories. If mitigation was chosen instead of patching, confirm the driver cannot be loaded and that USB device-control policy blocks untrusted USB audio devices. Do not validate by connecting unknown crafted USB devices to production systems; use an isolated test host if proof-of-fix testing is required.

Typical attack path

  1. Identify a Linux system that loads the ALSA caiaq USB audio driver or supports the affected USB audio device class.
  2. Gain local physical access, control over a USB peripheral, or the ability to emulate a USB device, such as through malicious hardware or a USB gadget platform.
  3. Configure the USB device product name or short name with a crafted sequence of non-space characters that fills the driver's local card ID buffer.
  4. Connect or present the crafted USB device to the target Linux system.
  5. Trigger kernel device initialization for the ALSA caiaq driver.
  6. Cause the malformed, unterminated card ID string to be passed into ALSA card ID handling.
  7. Trigger a stack out-of-bounds read, potentially causing a kernel warning, crash, panic, or limited disclosure of kernel stack memory.

How to detect it

Look for evidence of exploitation or attempted triggering in kernel logs, system journals, crash dumps, and endpoint telemetry around USB insertion events. Relevant sources include journalctl kernel logs, /var/log/kern.log, /var/log/messages, dmesg output, crash dump directories, kdump/vmcore artifacts, EDR device-control logs, and USB inventory logs. Focus on events involving ALSA, snd_usb_caiaq, caiaq, USB audio device enumeration, KASAN stack-out-of-bounds reports, kernel oops messages, or panics occurring immediately after a USB device was connected. On systems with KASAN or debug kernels, the most direct signal is a stack-out-of-bounds report in copy_valid_id_string or snd_card_set_id_no_lock. On production kernels without KASAN, look for unexplained kernel crashes, oops traces, or audio driver initialization failures correlated with new USB device descriptors containing unusual product names, high-bit UTF-8 characters, or malformed strings. There are no known threat actors, campaigns, or public exploit indicators associated with this vulnerability in the provided data, so detection should be behavior- and log-based rather than IOC-only.

  • BUG: KASAN: stack-out-of-bounds in copy_valid_id_string
  • BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock
  • sound/core/init.c:696
  • sound/core/init.c:718
  • snd_card_set_id_no_lock
  • copy_valid_id_string
  • snd_usb_caiaq
  • ALSA: caiaq
  • caiaq
  • stack-out-of-bounds
  • KASAN: stack-out-of-bounds
  • kernel: usb
  • kernel: ALSA

What your security team should do

  • Prioritize kernel updates on Linux systems where users can connect USB devices, especially workstations, kiosks, recording/audio systems, lab machines, and shared physical-access environments.
  • Inventory systems with the snd_usb_caiaq driver present or loaded and determine whether the hardware support is actually required.
  • If the driver is unnecessary, disable or blacklist snd_usb_caiaq as a compensating control until patched kernels are deployed.
  • Enforce USB peripheral controls, including allowlisting trusted device classes and blocking unknown USB audio devices where operationally feasible.
  • Monitor kernel logs for KASAN, stack-out-of-bounds, snd_card_set_id, copy_valid_id_string, and snd_usb_caiaq-related errors after USB device connection events.
  • Treat unexpected kernel panics or oops events following USB device insertion as potentially security-relevant and preserve logs for forensic review.
  • Because EPSS is low, exploit maturity is none, and the issue is not in KEV, handle this through normal high-severity kernel patch management unless the organization has high physical-access or untrusted-USB exposure.

The record

In the Linux kernel, the following vulnerability has been resolved: ALSA: caiaq: fix stack out-of-bounds read in init_card The loop creates a whitespace-stripped copy of the card shortname where `len < sizeof(card->id)` is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte. When this non-null-terminated string is later passed to snd_card_set_id() -> copy_valid_id_string(), the function scans forward with `while (*nid && ...)` and reads past the end of the stack buffer, reading the contents of the stack. A USB device with a product name containing many non-ASCII, non-space characters (e.g. multibyte UTF-8) will reliably trigger this as follows: BUG: KASAN: stack-out-of-bounds in copy_valid_id_string sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c sound/core/init.c:718 The off-by-one has been present since commit bafeee5b1f8d ("ALSA: snd_usb_caiaq: give better shortname") from June 2009 (v2.6.31-rc1), which first introduced this whitespace-stripping loop. The original code never accounted for the null terminator when bounding the copy. Fix this by changing the loop bound to `sizeof(card->id) - 1`, ensuring at least one byte remains as the null terminator.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities