CVE-2026-99271
ALSA: line6: Clear prev_fbuf on capture buffer release
What happened?
In the Linux kernel, the following vulnerability has been resolved:
ALSA: line6: Clear prev_fbuf on capture buffer release
A KASAN slab-use-after-free read was reported in submit_audio_out_urb() when generating an impulse test signal:
BUG: KASAN: slab-use-after-free in create_impulse_test_signal sound/usb/line6/playback.c:76 [inline] BUG: KASAN: slab-use-after-free in submit_audio_out_urb+0x1848/0x1b20 sound/usb/line6/playback.c:249 Read of size 2 at addr ffff888008d74870 by task syz.2.3214/7785
Allocated by task 11: kmem_cache_alloc_noprof+0x2f0/0x390 mm/slub.c:4144 line6_buffer_acquire+0x1a1/0x220 sound/usb/line6/pcm.c:158 line6_pcm_acquire+0xb6/0x230 sound/usb/line6/pcm.c:329 line6_startup_work+0x3c/0x50 sound/usb/line6/driver.c:728
Freed by task 7785: kfree+0xf8/0x390 mm/slub.c:6566 line6_buffer_release sound/usb/line6/pcm.c:176 [inline] line6_buffer_release+0xa5/0xf0 sound/usb/line6/pcm.c:170 __line6_pcm_release sound/usb/line6/pcm.c:305 [inline] line6_pcm_release+0x5a/0x80 sound/usb/line6/pcm.c:313 snd_toneport_monitor_put+0x11b/0x190 sound/usb/line6/toneport.c:183
line6pcm->prev_fbuf points into the capture PCM stream buffer (line6pcm->in.buffer), which is updated during audio_in_callback() to feed rate synchronization, software monitoring, and impulse test signal generation on playback side.
When all capture streams are closed, line6_buffer_release() frees pstr->buffer with kfree(). However, it does not clear line6pcm->prev_fbuf. If playback is subsequently started (e.g. via impulse test signal volume control snd_line6_impulse_volume_put()), submit_audio_out_urb() dereferences the stale pointer line6pcm->prev_fbuf under in.lock, resulting in a slab-use-after-free read.
Clear prev_fbuf and prev_fsize in line6_buffer_release() when releasing the capture stream buffer under in.lock, ensuring that no stale buffer pointer can be accessed by submit_audio_out_urb().
Affected software and versions
| Software | Version information | Fixed version |
|---|---|---|
| LinuxLinux | affected: 63e20df1e5b2ef8d871ecbdb6c038d554ed1ca74 to < 862d9268f40a6e10cef24eb226e738fb69ce8aa7; affected: 63e20df1e5b2ef8d871ecbdb6c038d554ed1ca74 to < 22c82f33ff0b68d37041adf1dea5533a5863cd31; affected: 63e20df1e5b2ef8d871ecbdb6c038d554ed1ca74 to < aa118c8f61d59387961d58ffae831c5259a9f222 | See vendor advisory |
| LinuxLinux | affected: 4.0; unaffected: 0 to < 4.0; unaffected: 6.18.61 to ≤ 6.18.*; unaffected: 7.3.2 to ≤ 7.3.*; unaffected: 7.4-rc1 to ≤ * | See vendor advisory |
Version information comes from the source record and can include unaffected products and exceptions. Distribution packages may contain backported fixes: an older upstream version alone does not prove a server is affected.
Is it being exploited?
This CVE was not listed in the CISA catalogue at our last retrieval. This does not establish that exploitation is absent.
How to respond
- Confirm the product, installed package version, and any configuration requirements in the vendor advisory.
- Follow the vendor’s remediation or workaround guidance in the references below. Structured fixed-version data is unavailable here; the publisher’s description may include a fix or workaround.
- Restart affected services if required, then verify the running version. Known exploitation may warrant investigation as well as patching.