https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 07:39:35 +0000 https://vulnerability.circl.lu/vuln/cve-2026-72443 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints</p> <p>MIDI 2.0 input URBs are started during snd_usb_midi_v2_create(). A later setup failure can still jump to snd_usb_midi_v2_free(), which currently frees each endpoint and its coherent URB buffers without first stopping the submitted URBs. A completion can then dereference the embedded URB context and endpoint state after they have been freed, or try to resubmit from the stale endpoint.</p> <p>This was observed as a KASAN slab-use-after-free in input_urb_complete().</p> <p>The buggy scenario involves two paths, with each column showing the order within that path:</p> <p>probe error path: USB completion path: 1. start_input_streams() submits 1. The HCD still owns a input URBs. submitted input URB. 2. A later setup helper returns 2. input_urb_complete() runs an error. with urb-&gt;context in ep. 3. snd_usb_midi_v2_free() frees 3. The completion reads ep endpoint storage and URB buffers. state and can requeue URBs.</p> <p>Make the endpoint destructor follow the same teardown ordering used for disconnect when the endpoint has not already been disconnected: publish ep-&gt;disconnected, kill the URBs synchronously, and drain the endpoint before freeing URB buffers and endpoint storage. The guard avoids repeating the stop sequence after the normal snd_usb_…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ALSA: usb-audio: Kill MIDI 2.0 URBs before freeing endpoints</p> <p>MIDI 2.0 input URBs are started during snd_usb_midi_v2_create(). A later setup failure can still jump to snd_usb_midi_v2_free(), which currently frees each endpoint and its coherent URB buffers without first stopping the submitted URBs. A completion can then dereference the embedded URB context and endpoint state after they have been freed, or try to resubmit from the stale endpoint.</p> <p>This was observed as a KASAN slab-use-after-free in input_urb_complete().</p> <p>The buggy scenario involves two paths, with each column showing the order within that path:</p> <p>probe error path: USB completion path: 1. start_input_streams() submits 1. The HCD still owns a input URBs. submitted input URB. 2. A later setup helper returns 2. input_urb_complete() runs an error. with urb-&gt;context in ep. 3. snd_usb_midi_v2_free() frees 3. The completion reads ep endpoint storage and URB buffers. state and can requeue URBs.</p> <p>Make the endpoint destructor follow the same teardown ordering used for disconnect when the endpoint has not already been disconnected: publish ep-&gt;disconnected, kill the URBs synchronously, and drain the endpoint before freeing URB buffers and endpoint storage. The guard avoids repeating the stop sequence after the normal snd_usb_…</p> https://vulnerability.circl.lu/vuln/cve-2026-72443