CVE-2026-98836

Low risk· EPSS 6%

Published: 18/10/2026(UTC)Updated: 30/10/2026(UTC)Translated: 18/10/2026(UTC)NVD NIST

Exploitation Probability (EPSS)

Low risk

0.17%

6th percentile - higher than 6% of all known CVEs

Summary

In the Linux kernel ALSA line6 driver (sound/usb/line6/playback.c), the number of bytes written into a playback URB buffer slice was never validated against the slice size. When a USB device declares a large IN wMaxPacketSize and a small OUT wMaxPacketSize, submit_audio_out_urb() performs a memcpy()/memset() beyond the allocated region, causing a slab-out-of-bounds write.

Risk Assessment

The vulnerability can cause kernel memory corruption, system crash (panic), or potentially kernel code execution when a specially crafted USB device is connected. Exploitation requires physical access to a USB port or the ability to attach a malicious device.

Recommendation

Update the Linux kernel to a version containing the fix that rejects packets exceeding the allocated buffer slice size. Until patched, avoid connecting untrusted USB audio devices supported by the line6 driver.

Other vulnerabilities in Linux kernel (ALSA line6 driver)

CVE-2026-99271Unknown
A use-after-free vulnerability exists in the Linux kernel ALSA line6 driver. line6_buffer_release() frees the capture stream buffer but does not clear the line6pcm->prev_fbuf pointer, which is later dereferenced in submit_audio_out_urb() during playback, causing a slab-use-after-free read.

Original NVD description (English source)

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)

Vulnerability data from NVD (NIST) · CISA KEV · EPSS