Cloudanix VulnDB

CVE-2026-98741

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in handling certain USB audio equipment can corrupt memory inside the operating system when the device is plugged in, potentially crashing the computer or allowing an attacker with physical access to gain more control.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Privilege Gain
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds write in the ALSA ua101 driver caused by mismatched wMaxPacketSize and channel counts between capture and playback USB endpoints, allowing memcpy and memset to exceed the allocated playback buffer during PCM open.

Why it matters to the business

Kernel memory corruption on systems exposing the ua101 driver to untrusted USB audio devices can lead to crashes, denial of service, or potential local privilege escalation; the issue remains unexploited in the wild and carries low public exploitability.

How an attack unfolds

An attacker supplies a crafted USB device descriptor declaring a large capture packet size with few channels and a small playback packet size with many channels; when the driver probes and a user opens the PCM device, start_usb_playback performs an oversized write past the end of the kmalloc-192 buffer.

How to fix it

Update to a kernel containing the fix that rejects mismatched capture/playback wMaxPacketSize and bNrChannels descriptors at probe time in sound/usb/misc/ua101.c; rebuild and reboot after installing the corrected kernel package.

How to confirm the fix worked

Confirm the patched ua101.c rejects mismatched descriptors at probe; attempt to load the driver with a synthetic device exposing disproportionate packet sizes and verify -EINVAL is returned before any PCM open occurs.

Typical attack path

  1. Attacker presents malicious USB audio device to the target system
  2. Kernel loads ua101 driver and calls detect_usb_format during probe
  3. User or automated process opens the registered PCM playback node
  4. playback_pcm_open invokes start_usb_playback which performs the out-of-bounds memset
  5. usb_submit_urb later rejects the URB but the write has already occurred

How to detect it

Search kernel logs and audit trails for KASAN slab-out-of-bounds reports mentioning ua101.c, start_usb_playback, or playback_pcm_open; inspect dmesg and systemd journal around USB device enumeration events for ua101 probe failures.

What your security team should do

  • Apply the corrected kernel as soon as it is available in your distribution
  • Restrict physical or virtual USB access for untrusted devices until patched
  • Monitor kernel logs for KASAN reports referencing ua101.c or start_usb_playback

The record

In the Linux kernel, the following vulnerability has been resolved: ALSA: ua101: reject mismatched capture/playback packet sizes detect_usb_format() cross-checks bSubframeSize, bBitResolution and tSamFreq between the capture and playback interfaces, but never relates the two endpoints' wMaxPacketSize and bNrChannels. Each playback URB gets a buffer of ua->playback.max_packet_bytes, while the number of bytes written into it is derived from the capture stream: capture_urb_complete() computes frames from the received capture packet and capture.frame_bytes, and start_usb_playback() and playback_work() multiply that by playback.frame_bytes. A device declaring a large capture wMaxPacketSize with few capture channels and a small playback wMaxPacketSize with many playback channels therefore memset()s and memcpy()s past the end of the playback buffer, in open() of the PCM node the driver registers during probe. usb_submit_urb() rejects the over-long iso_frame_desc[0].length with -EMSGSIZE, but only after the write. Reject such descriptors at probe time. Genuine UA-101/UA-1000 hardware declares proportional packet sizes and is unaffected. BUG: KASAN: slab-out-of-bounds in start_usb_playback (sound/usb/misc/ua101.c:586) Write of size 2048 at addr ffff8881098f3c00 by task exploit/5021 Call Trace: __asan_memset (mm/kasan/shadow.c:84) start_usb_playback (sound/usb/misc/ua101.c:586) playback_pcm_open (sound/usb/misc/ua101.c:679) snd_pcm_open_substream (sound/core/pcm_native.c:2829) snd_pcm_open (sound/core/pcm_native.c:2865 sound/core/pcm_native.c:2932) snd_pcm_playback_open (sound/core/pcm_native.c:2891) snd_open (sound/core/sound.c:166) chrdev_open (fs/char_dev.c:411) do_dentry_open (fs/open.c:996) vfs_open (fs/open.c:1101) path_openat (fs/namei.c:4837 fs/namei.c:5000) do_file_open (fs/namei.c:5029) do_sys_openat2 (fs/open.c:1417) __x64_sys_openat (fs/open.c:1423 fs/open.c:1439 fs/open.c:1434) do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) The buggy address belongs to the object at ffff8881098f3c00 which belongs to the cache kmalloc-192 of size 192 The buggy address is located 0 bytes inside of allocated 168-byte region [ffff8881098f3c00, ffff8881098f3ca8)

Affected packages

Ecosystem Package Introduced Fixed