CVE-2026-98836 in Linux
Summary
by MITRE • 10/18/2026
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)
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel’s ALSA USB line6 driver contains a critical out-of-bounds write vulnerability that arises from an insufficient validation of packet sizes during audio playback operations. This flaw is located in the submit_audio_out_urb function within sound/usb/line6/playback.c, where the driver allocates a buffer slice for each Playback Unit Request Block (URB) based on the product of LINE6_ISO_PACKETS and max_packet_size_out derived from the USB OUT endpoint configuration. However, the code fails to verify that the actual number of bytes intended for transmission does not exceed this allocated size. The data volume is determined by rescaling frame counts obtained from previous input packets or synthesized via sample rate calculations when no prior packet length exists. This logic creates a dangerous discrepancy when connected devices report a large maximum packet size for their IN endpoint but a significantly smaller one for the OUT endpoint, leading to write operations that exceed buffer boundaries.
The technical root cause lies in how USB core validation interacts with driver-level memory management. The usb_maxpacket function retrieves only the lower eleven bits of the wMaxPacketSize field, which may not accurately reflect the true capacity or intended limits when combined with multiplier factors used by the USB subsystem for high-speed isochronous transfers. Consequently, a URB can be submitted with a length up to three times larger than the allocated slice without immediate rejection by the core stack. Since usb_submit_urb serves primarily as an asynchronous submission mechanism rather than a strict validation gatekeeper in this context, the oversized write occurs before any potential error handling can intervene. This results in slab-out-of-bounds memory corruption, specifically manifesting as writes beyond a 256-byte kmalloc allocation region, which triggers Kernel Address Sanitizer (KASAN) alerts and indicates severe heap overflow conditions that compromise kernel integrity.
From an operational perspective, this vulnerability allows for potential denial of service through system crashes or panics due to the corrupted memory state. In more sophisticated attack scenarios, such out-of-bounds writes could facilitate arbitrary code execution if an attacker can control the data being written into the adjacent memory regions. The issue is particularly relevant in environments where untrusted USB audio devices are connected, as it exploits the trust placed in device descriptors without adequate bounds checking on the resulting buffer operations. The lack of synchronization between input-derived frame sizes and output allocation limits creates a predictable path for exploitation, especially when dealing with malformed or maliciously crafted USB descriptors that declare disparate packet sizes for inbound versus outbound streams.
To mitigate this risk, it is imperative to enforce strict size validation before performing memory copy or set operations within the playback URB submission logic. The driver must compare the calculated byte count against the allocated slice size and reject any packets that exceed the boundary rather than attempting to clamp them, as clamping would desynchronize audio streams by silently altering capture-derived rate feedback. Implementing explicit checks ensures that only valid data ranges are processed, preserving both system stability and audio stream integrity. This fix aligns with best practices for preventing heap-based buffer overflows in kernel drivers handling external hardware interfaces.
This vulnerability is classified under CWE-120, which covers Buffer Copy without Checking Size of Input, as the core failure involves copying data into a buffer without verifying that the input length fits within the destination bounds. Additionally, it relates to CWE-787, an Out-of-bounds Write condition where memory is written beyond its allocated limit. In terms of attack vectors and tactics, this flaw can be leveraged in attacks categorized under MITRE ATT&CK technique T1203, Exploitation for Defense Evasion or Privilege Escalation via USB device interaction, specifically targeting driver-level vulnerabilities to gain higher privileges within the operating system kernel environment.