Live › vulnerability › CVE-2026-98836
Go to dashboardThe 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 written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only systems that load the line6 ALSA USB driver are exposed, which means machines with a Line 6 USB audio interface or a device that presents itself as one. The bug needs a USB device whose IN endpoint declares a large wMaxPacketSize and a small OUT endpoint, so ordinary hosts without line6 hardware or the module can skip it. Exploitation requires physical attachment of a malicious USB device.
No product ranges from the sources yet.
uname -r and compare against the fixed kernel builds listed in the kernel stable advisory for CVE-2026-98836lsmod | grep line6 to see whether the line6 driver is loadedlsusb | grep -i line6modprobe -r snd-usb-line6 if no Line 6 device is neededEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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)
This page as .md · .json · in your agent: get_signal("CVE-2026-98836")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.