<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T20:52:09.220136+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/bell-cve-2026-68124</id>
    <title>BELL-CVE-2026-68124</title>
    <updated>2026-10-02T20:52:09.997430+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2026-68124"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069</id>
    <title>certfr-2026-avi-1069 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Elles permettent à un attaquant de p…</title>
    <updated>2026-10-02T20:52:09.997517+00:00</updated>
    <content>certfr-2026-avi-1069</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-356004</id>
    <title>EUVD-2026-356004</title>
    <updated>2026-10-02T20:52:09.997539+00:00</updated>
    <content>EUVD-2026-356004</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-356004"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-68124</id>
    <title>fkie_cve-2026-68124</title>
    <updated>2026-10-02T20:52:09.997553+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>mctp: serial: handle zero-length frames to prevent rx buffer overflow</p>
<p>The MCTP serial receive state machine reads a frame length byte in
mctp_serial_push_header() case 2 and validates it upper-bound-only:</p>
<p>if (c &gt; MCTP_SERIAL_FRAME_MTU) {
		dev-&gt;rxstate = STATE_ERR;
	} else {
		dev-&gt;rxlen = c;
		dev-&gt;rxpos = 0;
		dev-&gt;rxstate = STATE_DATA;
		...
	}</p>
<p>A length of zero passes this check, so rxlen is set to 0 and the state
machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the
incoming byte is stored and rxpos incremented before the terminator is</p>
<p>dev-&gt;rxbuf[dev-&gt;rxpos] = c;
	dev-&gt;rxpos++;
	dev-&gt;rxstate = STATE_DATA;
	if (dev-&gt;rxpos == dev-&gt;rxlen) {
		dev-&gt;rxpos = 0;
		dev-&gt;rxstate = STATE_TRAILER;
	}</p>
<p>With rxlen == 0 the "rxpos == rxlen" terminator can never fire (rxpos is
already 1 on the first data byte), so subsequent bytes are written past
the end of the fixed 74-byte rxbuf, which is the last member of the
netdev private area. Every following data byte is an attacker-controlled
1-byte out-of-bounds heap write, and the overflow continues until a
frame (0x7e) or escape byte resets the parser -- effectively unbounded.</p>
<p>Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line
discipline and bring the resulting mctpserialN netdev up, after which
the bytes arrive via the tty receive path.</p>
<p>Route a zero-length frame straight to STATE_TRAILER instead of
STATE_DATA. The trailer/framing bytes…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-68124"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-c8wc-v527-8f9g</id>
    <title>GHSA-c8wc-v527-8f9g</title>
    <updated>2026-10-02T20:52:09.997605+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>mctp: serial: handle zero-length frames to prevent rx buffer overflow</p>
<p>The MCTP serial receive state machine reads a frame length byte in
mctp_serial_push_header() case 2 and validates it upper-bound-only:</p>
<p>if (c &gt; MCTP_SERIAL_FRAME_MTU) {
		dev-&gt;rxstate = STATE_ERR;
	} else {
		dev-&gt;rxlen = c;
		dev-&gt;rxpos = 0;
		dev-&gt;rxstate = STATE_DATA;
		...
	}</p>
<p>A length of zero passes this check, so rxlen is set to 0 and the state
machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the
incoming byte is stored and rxpos incremented before the terminator is</p>
<p>dev-&gt;rxbuf[dev-&gt;rxpos] = c;
	dev-&gt;rxpos++;
	dev-&gt;rxstate = STATE_DATA;
	if (dev-&gt;rxpos == dev-&gt;rxlen) {
		dev-&gt;rxpos = 0;
		dev-&gt;rxstate = STATE_TRAILER;
	}</p>
<p>With rxlen == 0 the "rxpos == rxlen" terminator can never fire (rxpos is
already 1 on the first data byte), so subsequent bytes are written past
the end of the fixed 74-byte rxbuf, which is the last member of the
netdev private area. Every following data byte is an attacker-controlled
1-byte out-of-bounds heap write, and the overflow continues until a
frame (0x7e) or escape byte resets the parser -- effectively unbounded.</p>
<p>Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line
discipline and bring the resulting mctpserialN netdev up, after which
the bytes arrive via the tty receive path.</p>
<p>Route a zero-length frame straight to STATE_TRAILER instead of
STATE_DATA. The trailer/framing bytes…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-c8wc-v527-8f9g"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2026-68124</id>
    <title>msrc_CVE-2026-68124 — mctp: serial: handle zero-length frames to prevent rx buffer overflow</title>
    <updated>2026-10-02T20:52:09.997643+00:00</updated>
    <content>msrc_CVE-2026-68124</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2026-68124"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1</id>
    <title>openSUSE-SU-2026:21910-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T20:52:09.997661+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2026:23881-1</id>
    <title>SUSE-SU-2026:23881-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T20:52:09.998153+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2026:23881-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68124</id>
    <title>UBUNTU-CVE-2026-68124</title>
    <updated>2026-10-02T20:52:09.998633+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 154 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: mctp: serial: handle zero-length frames to prevent rx buffer overflow The MCTP serial receive state machine reads a frame length byte in mctp_serial_push_header() case 2 and validates it upper-bound-only: 	if (c &gt; MCTP_SERIAL_FRAME_MTU) { 		dev-&gt;rxstate = STATE_ERR; 	} else { 		dev-&gt;rxlen = c; 		dev-&gt;rxpos = 0; 		dev-&gt;rxstate = STATE_DATA; 		... 	} A length of zero passes this check, so rxlen is set to 0 and the state machine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the incoming byte is stored and rxpos incremented before the terminator is 	dev-&gt;rxbuf[dev-&gt;rxpos] = c; 	dev-&gt;rxpos++; 	dev-&gt;rxstate = STATE_DATA; 	if (dev-&gt;rxpos == dev-&gt;rxlen) { 		dev-&gt;rxpos = 0; 		dev-&gt;rxstate = STATE_TRAILER; 	} With rxlen == 0 the "rxpos == rxlen" terminator can never fire (rxpos is already 1 on the first data byte), so subsequent bytes are written past the end of the fixed 74-byte rxbuf, which is the last member of the netdev private area. Every following data byte is an attacker-controlled 1-byte out-of-bounds heap write, and the overflow continues until a frame (0x7e) or escape byte resets the parser -- effectively unbounded. Reaching this requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring the resulting mctpserialN netdev up, after which the bytes arrive via the tty receive path. Route a zero-length frame straight to STATE_TRAILER instead of STATE_DATA. The trailer/framing bytes are sti…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68124"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730</id>
    <title>WID-SEC-W-2026-2730 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-02T20:52:09.998835+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730"/>
  </entry>
</feed>
