<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-29T15:59:26.666669+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-80973</id>
    <title>CVE-2026-80973 — ALSA: 6fire: bound the MIDI event length from the device</title>
    <updated>2026-09-29T15:59:27.514068+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>ALSA: 6fire: bound the MIDI event length from the device</p>
<p>usb6fire_comm_receiver_handler() forwards a MIDI event using a length
byte the device supplies, with no bound and no check that the transfer
delivered that many bytes:</p>
<p>if (!urb-&gt;status) {
		if (rt-&gt;receiver_buffer[0] == 0x10) /* midi in event */
			if (midi_rt)
				midi_rt-&gt;in_received(midi_rt,
						rt-&gt;receiver_buffer + 2,
						rt-&gt;receiver_buffer[1]);
	}</p>
<p>receiver_buffer is a 64-byte kzalloc() buffer (COMM_RECEIVER_BUFSIZE), so
only 62 bytes follow the two-byte header.  receiver_buffer[1] is a u8 the
device chooses, so a device that answers with 0x10 and a length of 0xFF
makes snd_rawmidi_receive() read 255 bytes starting two bytes into a
64-byte object.  The bytes past the buffer are handed to userspace
through the rawmidi read path.</p>
<p>urb-&gt;actual_length is not consulted either, so a short transfer leaves
both the type byte and the length byte at their previous values and the
handler acts on stale data.</p>
<p>The receiver URB is submitted from usb6fire_comm_init() at probe, so the
read happens on plug with no user action; forwarding to userspace also
needs a MIDI input substream open, since usb6fire_midi_in_received()
only calls snd_rawmidi_receive() when rt-&gt;in is set.</p>
<p>KASAN on 7.2.0-rc5 (arm64), single packet from an emulated device:</p>
<p>BUG: KASAN: slab-out-of-bounds in snd_rawmidi_receive
  Read of size 255 at addr ffff000009f64682 by task bash/…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-80973"/>
  </entry>
</feed>
