CVE-2026-98836

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)