<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 03 Oct 2026 01:44:11 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-68124</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-68124</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-68124</guid>
    </item>
    <item>
      <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>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069</link>
      <description>certfr-2026-avi-1069</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1069</guid>
    </item>
    <item>
      <title>EUVD-2026-356004</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-356004</link>
      <description>EUVD-2026-356004</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-356004</guid>
    </item>
    <item>
      <title>fkie_cve-2026-68124</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-68124</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mctp: serial: handle zero-length frames to prevent rx buffer overflow&lt;/p&gt;
&lt;p&gt;The MCTP serial receive state machine reads a frame length byte in
mctp_serial_push_header() case 2 and validates it upper-bound-only:&lt;/p&gt;
&lt;p&gt;if (c &amp;gt; MCTP_SERIAL_FRAME_MTU) {
		dev-&amp;gt;rxstate = STATE_ERR;
	} else {
		dev-&amp;gt;rxlen = c;
		dev-&amp;gt;rxpos = 0;
		dev-&amp;gt;rxstate = STATE_DATA;
		...
	}&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;dev-&amp;gt;rxbuf[dev-&amp;gt;rxpos] = c;
	dev-&amp;gt;rxpos++;
	dev-&amp;gt;rxstate = STATE_DATA;
	if (dev-&amp;gt;rxpos == dev-&amp;gt;rxlen) {
		dev-&amp;gt;rxpos = 0;
		dev-&amp;gt;rxstate = STATE_TRAILER;
	}&lt;/p&gt;
&lt;p&gt;With rxlen == 0 the &amp;#34;rxpos == rxlen&amp;#34; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Route a zero-length frame straight to STATE_TRAILER instead of
STATE_DATA. The trailer/framing bytes…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mctp: serial: handle zero-length frames to prevent rx buffer overflow&lt;/p&gt;
&lt;p&gt;The MCTP serial receive state machine reads a frame length byte in
mctp_serial_push_header() case 2 and validates it upper-bound-only:&lt;/p&gt;
&lt;p&gt;if (c &amp;gt; MCTP_SERIAL_FRAME_MTU) {
		dev-&amp;gt;rxstate = STATE_ERR;
	} else {
		dev-&amp;gt;rxlen = c;
		dev-&amp;gt;rxpos = 0;
		dev-&amp;gt;rxstate = STATE_DATA;
		...
	}&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;dev-&amp;gt;rxbuf[dev-&amp;gt;rxpos] = c;
	dev-&amp;gt;rxpos++;
	dev-&amp;gt;rxstate = STATE_DATA;
	if (dev-&amp;gt;rxpos == dev-&amp;gt;rxlen) {
		dev-&amp;gt;rxpos = 0;
		dev-&amp;gt;rxstate = STATE_TRAILER;
	}&lt;/p&gt;
&lt;p&gt;With rxlen == 0 the &amp;#34;rxpos == rxlen&amp;#34; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Route a zero-length frame straight to STATE_TRAILER instead of
STATE_DATA. The trailer/framing bytes…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-68124</guid>
    </item>
    <item>
      <title>GHSA-c8wc-v527-8f9g</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-c8wc-v527-8f9g</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mctp: serial: handle zero-length frames to prevent rx buffer overflow&lt;/p&gt;
&lt;p&gt;The MCTP serial receive state machine reads a frame length byte in
mctp_serial_push_header() case 2 and validates it upper-bound-only:&lt;/p&gt;
&lt;p&gt;if (c &amp;gt; MCTP_SERIAL_FRAME_MTU) {
		dev-&amp;gt;rxstate = STATE_ERR;
	} else {
		dev-&amp;gt;rxlen = c;
		dev-&amp;gt;rxpos = 0;
		dev-&amp;gt;rxstate = STATE_DATA;
		...
	}&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;dev-&amp;gt;rxbuf[dev-&amp;gt;rxpos] = c;
	dev-&amp;gt;rxpos++;
	dev-&amp;gt;rxstate = STATE_DATA;
	if (dev-&amp;gt;rxpos == dev-&amp;gt;rxlen) {
		dev-&amp;gt;rxpos = 0;
		dev-&amp;gt;rxstate = STATE_TRAILER;
	}&lt;/p&gt;
&lt;p&gt;With rxlen == 0 the &amp;#34;rxpos == rxlen&amp;#34; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Route a zero-length frame straight to STATE_TRAILER instead of
STATE_DATA. The trailer/framing bytes…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;mctp: serial: handle zero-length frames to prevent rx buffer overflow&lt;/p&gt;
&lt;p&gt;The MCTP serial receive state machine reads a frame length byte in
mctp_serial_push_header() case 2 and validates it upper-bound-only:&lt;/p&gt;
&lt;p&gt;if (c &amp;gt; MCTP_SERIAL_FRAME_MTU) {
		dev-&amp;gt;rxstate = STATE_ERR;
	} else {
		dev-&amp;gt;rxlen = c;
		dev-&amp;gt;rxpos = 0;
		dev-&amp;gt;rxstate = STATE_DATA;
		...
	}&lt;/p&gt;
&lt;p&gt;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&lt;/p&gt;
&lt;p&gt;dev-&amp;gt;rxbuf[dev-&amp;gt;rxpos] = c;
	dev-&amp;gt;rxpos++;
	dev-&amp;gt;rxstate = STATE_DATA;
	if (dev-&amp;gt;rxpos == dev-&amp;gt;rxlen) {
		dev-&amp;gt;rxpos = 0;
		dev-&amp;gt;rxstate = STATE_TRAILER;
	}&lt;/p&gt;
&lt;p&gt;With rxlen == 0 the &amp;#34;rxpos == rxlen&amp;#34; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Route a zero-length frame straight to STATE_TRAILER instead of
STATE_DATA. The trailer/framing bytes…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-c8wc-v527-8f9g</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-68124 — mctp: serial: handle zero-length frames to prevent rx buffer overflow</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-68124</link>
      <description>msrc_CVE-2026-68124</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-68124</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21910-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:21910-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23881-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23881-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:23881-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-68124</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68124</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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 &amp;gt; MCTP_SERIAL_FRAME_MTU) { 		dev-&amp;gt;rxstate = STATE_ERR; 	} else { 		dev-&amp;gt;rxlen = c; 		dev-&amp;gt;rxpos = 0; 		dev-&amp;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-&amp;gt;rxbuf[dev-&amp;gt;rxpos] = c; 	dev-&amp;gt;rxpos++; 	dev-&amp;gt;rxstate = STATE_DATA; 	if (dev-&amp;gt;rxpos == dev-&amp;gt;rxlen) { 		dev-&amp;gt;rxpos = 0; 		dev-&amp;gt;rxstate = STATE_TRAILER; 	} With rxlen == 0 the &amp;#34;rxpos == rxlen&amp;#34; 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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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 &amp;gt; MCTP_SERIAL_FRAME_MTU) { 		dev-&amp;gt;rxstate = STATE_ERR; 	} else { 		dev-&amp;gt;rxlen = c; 		dev-&amp;gt;rxpos = 0; 		dev-&amp;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-&amp;gt;rxbuf[dev-&amp;gt;rxpos] = c; 	dev-&amp;gt;rxpos++; 	dev-&amp;gt;rxstate = STATE_DATA; 	if (dev-&amp;gt;rxpos == dev-&amp;gt;rxlen) { 		dev-&amp;gt;rxpos = 0; 		dev-&amp;gt;rxstate = STATE_TRAILER; 	} With rxlen == 0 the &amp;#34;rxpos == rxlen&amp;#34; 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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-68124</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2730 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2730</guid>
    </item>
  </channel>
</rss>
