Cloudanix VulnDB

CVE-2026-98836

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in Linux audio handling for certain USB music devices can let specially crafted hardware corrupt kernel memory, potentially crashing the system or allowing deeper attacks.

Exploitation
Physical Access
Attacker needs
Physical Access
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds write in submit_audio_out_urb when a USB audio device reports a large IN wMaxPacketSize and small OUT wMaxPacketSize, allowing memcpy or memset to exceed the allocated URB buffer slice derived from LINE6_ISO_PACKETS * max_packet_size_out.

Why it matters to the business

Kernel memory corruption on systems using Line 6 USB audio interfaces can cause crashes, denial of service, or potential privilege escalation; low exploitability keeps immediate risk limited despite recent disclosure.

How an attack unfolds

An attacker attaches a malicious or misbehaving high-speed USB audio device declaring mismatched endpoint packet sizes; when the driver starts the PCM stream via line6_pcm_acquire, line6_startup_work triggers audio_in_callback to set prev_fsize, which submit_audio_out_urb then uses to write past the allocated slice without bounds checking.

How to fix it

Apply the upstream kernel patch that adds explicit size validation in submit_audio_out_urb before the memcpy/memset; rebuild and deploy the fixed kernel on affected systems; avoid using untrusted USB audio devices until patched.

How to confirm the fix worked

Confirm kernel source contains the added packet-size check against the allocated slice in sound/usb/line6/playback.c; test with a device advertising mismatched wMaxPacketSize values and verify no KASAN slab-out-of-bounds occurs on stream start.

Typical attack path

  1. Connect USB device with oversized IN endpoint packet size relative to OUT
  2. Trigger ALSA PCM stream acquisition on the Line 6 interface
  3. line6_startup_work queues line6_submit_audio_out_all_urbs
  4. submit_audio_out_urb performs unbounded memcpy or memset using prev_fsize-derived length
  5. Write exceeds kmalloc-256 allocation, triggering slab-out-of-bounds

How to detect it

Search kernel logs and KASAN reports for slab-out-of-bounds in submit_audio_out_urb or line6_startup_work; inspect dmesg and audit logs for unexpected Line 6 PCM stream starts from unknown USB devices shortly after attach.

  • BUG: KASAN: slab-out-of-bounds in submit_audio_out_urb
  • sound/usb/line6/playback.c:229
  • line6_startup_work
  • Write of size 1024 at addr
  • kmalloc-256

What your security team should do

  • Inventory systems exposing Line 6 USB audio drivers and schedule kernel updates within the next maintenance window
  • Monitor for USB audio device attach events on endpoints using the line6 driver
  • Apply defense-in-depth by disabling unused USB audio classes where Line 6 devices are not required

The record

In the Linux kernel, the following vulnerability has been resolved: ALSA: line6: reject oversized playback packets Each playback URB is handed a slice of out.buffer that is exactly LINE6_ISO_PACKETS * max_packet_size_out bytes, sized from the OUT endpoint, but the number of bytes written into that slice is never compared against it. submit_audio_out_urb() takes the frame count from prev_fsize, which audio_in_callback() derived from the *IN* endpoint's received packet length, and rescales it with the playback frame size; when prev_fsize is still zero it synthesizes a length from the sample rate instead. On a device declaring a large IN wMaxPacketSize and a small OUT wMaxPacketSize, the resulting memcpy(), or the memset() when the playback stream is idle, runs past its slice and, as the reproducer below shows, beyond the allocation. usb_submit_urb() is not a backstop. max_packet_size_out comes from usb_maxpacket(), which returns only the low 11 bits of wMaxPacketSize, while USB core validates a high-speed isochronous length against that base scaled by usb_endpoint_maxp_mult(). A length of up to three times the allocated slice is therefore accepted, and even a rejected URB is only rejected after the write. Reject a packet that does not fit the slice the driver allocated for it. Clamping it instead would silently shorten the capture-derived rate feedback and desynchronize the two streams. BUG: KASAN: slab-out-of-bounds in submit_audio_out_urb (sound/usb/line6/playback.c:229) Write of size 1024 at addr ffff888100bbd400 by task kworker/1:2/5002 Workqueue: events line6_startup_work Call Trace: __asan_memcpy (mm/kasan/shadow.c:106) submit_audio_out_urb (sound/usb/line6/playback.c:229) line6_submit_audio_out_all_urbs (sound/usb/line6/playback.c:291) line6_stream_start (sound/usb/line6/pcm.c:194) line6_pcm_acquire (sound/usb/line6/pcm.c:337) line6_startup_work (sound/usb/line6/driver.c:728) process_one_work (kernel/workqueue.c:3396) worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) The buggy address belongs to the object at ffff888100bbd400 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 0 bytes inside of allocated 256-byte region [ffff888100bbd400, ffff888100bbd500)

Affected packages

Ecosystem Package Introduced Fixed