---
id: "CVE-2026-98836"
kind: "vulnerability"
aliases: ["CVE-2026-98836"]
title: "Linux kernel line6 driver: oversized USB playback packets overflow memory"
severity: "high"
cvss: null
epss: null
exploited: false
status: "open"
category: "infrastructure"
products: []
ecosystems: []
tags: ["alsa", "infrastructure", "line6", "linux-kernel", "usb-audio"]
not_affected_if: ["driver-not-loaded", "no-line6-hardware", "physical-access-controlled"]
published_at: "2026-10-18T16:17:37+00:00"
first_seen_at: "2026-10-23T21:57:17+00:00"
updated_at: "2026-10-25T05:13:18+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-98836", "first_seen_at": "2026-10-23T21:57:17+00:00"}]
---

# Linux kernel line6 driver: oversized USB playback packets overflow memory

The Linux ALSA line6 USB audio driver copies playback data into a buffer without checking its size, so a crafted USB device with a large IN endpoint packet size can write past the allocated memory. KASAN reports a slab out-of-bounds write from a kernel workqueue, which can corrupt kernel memory.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- `uname -r` and compare against the fixed kernel builds listed in the kernel stable advisory for CVE-2026-98836
- `lsmod | grep line6` to see whether the line6 driver is loaded
- Check whether a Line 6 USB audio device is attached with `lsusb | grep -i line6`

## Fix

- Update the Linux kernel to a stable release that includes the upstream commit 'ALSA: line6: reject oversized playback packets'
- Until patched, unload the driver with `modprobe -r snd-usb-line6` if no Line 6 device is needed

## Timeline

- 2026-10-23T21:57:17+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-98836

## From the sources

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)

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_