ALSA: bcd2000: clear the URB pointers on disconnect

Overview

In the Linux kernel, the following vulnerability has been resolved:

ALSA: bcd2000: clear the URB pointers on disconnect

bcd2000_free_usb_related_resources() frees both URBs and leaves the pointers behind:

usb_kill_urb(bcd2k->midi_out_urb);
usb_kill_urb(bcd2k->midi_in_urb);

usb_free_urb(bcd2k->midi_out_urb);
usb_free_urb(bcd2k->midi_in_urb);

The rawmidi device outlives that call. A substream that is still open when the device is unplugged reaches bcd2000_midi_send() from the trigger path on close. That function writes to the freed URB and then hands it to the USB core:

bcd2k->midi_out_urb->transfer_buffer_length = BUFSIZE;
...
ret = usb_submit_urb(bcd2k->midi_out_urb, GFP_ATOMIC);

usb_kill_urb() does not stop a later submission either, so a submit that races the disconnect can requeue the URB after it has been reaped. midi_in_urb is exposed the same way: bcd2000_input_complete() resubmits it from the completion handler.

KASAN on 7.2.0-rc5 (arm64):

BUG: KASAN: slab-use-after-free in bcd2000_midi_send [snd_bcd2000] Write of size 4 at addr ffff00001827d388 by task bpoc/168 __asan_store4 bcd2000_midi_send [snd_bcd2000] bcd2000_midi_output_trigger [snd_bcd2000] snd_rawmidi_kernel_write1 close_substream.part.0 Freed by task 168: usb_free_urb bcd2000_disconnect [snd_bcd2000]

BUG: KASAN: slab-use-after-free in usb_submit_urb Read of size 8 at addr ffff00001827d3b8 by task bpoc/168

Clear both pointers after freeing and test them on the paths that can still run. Poison the URBs before freeing them: usb_poison_urb() waits for a running completion handler and rejects any later submission, so after it returns the input path is quiesced and only the rawmidi trigger path can still reach bcd2000_midi_send(). No unpoison is needed; the URBs are freed on the next line.

Discovered by XBOW, triaged by Baul Lee [email protected]

Affected

• Linux >= b47a22290d581277be70e8a597824a4985d39e83 < 9af08677aa57debaca5b57c8045c52a83d3dd376
• Linux >= b47a22290d581277be70e8a597824a4985d39e83 < 5a77febac6faf6da40fbb4555f703eeb91b58130
• Linux >= b47a22290d581277be70e8a597824a4985d39e83 < 3c00004f134fc819f9d9e202c6a64acde0a1f8d0
• Linux >= b47a22290d581277be70e8a597824a4985d39e83 < 6c07aad8a7c9ef8ebc4d03a964b882123a349a2e
• Linux >= b47a22290d581277be70e8a597824a4985d39e83 < eb482a06791d6168beb8c78cc904ac5a5ed96a55
• Linux >= b47a22290d581277be70e8a597824a4985d39e83 < 7df3194bdb7479cad9199889655a566a2c0c1d1b
• Linux >= b47a22290d581277be70e8a597824a4985d39e83 < b06ebc7fe25a6af4a9f6e4a3d4236a4178ad4b01
• Linux >= b47a22290d581277be70e8a597824a4985d39e83 < 459d3a64766f5ca2f1886daeaf24582831a5f5ab
• Linux 3.16

Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.

Vendor advisories

• Red Hat VEX · Moderate · affected: Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4 · no fix planned: Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 10, Red Hat Enterprise Linux 7, Red Hat Enterprise Linux 8, … · updated 2026-09-14 · vex