Cloudanix VulnDB

CVE-2026-68124

Critical · 9.6

CVSS

9.6

EPSS

0.3%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in how the Linux kernel processes certain serial network messages can let an attacker overwrite memory and potentially take over the system or cause it to crash.

Exploitation
Local Privilege
Attacker needs
High Privilege
Complexity
Moderate
Impact
Remote Code Execution
Component
OS kernel
Class
Buffer Overflow
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Zero-length frame handling in the MCTP serial receive state machine allows an unbounded out-of-bounds heap write into the fixed-size rxbuf within the netdev private area when attacker-controlled bytes arrive over the tty path after CAP_NET_ADMIN attachment of the N_MCTP line discipline.

Why it matters to the business

Systems relying on MCTP serial links face risk of kernel memory corruption that can lead to crashes, privilege escalation, or remote code execution, potentially disrupting network-attached devices and embedded Linux deployments until patched.

How an attack unfolds

An attacker with the ability to attach the N_MCTP line discipline to a tty and bring the resulting netdev up sends a crafted zero-length frame (0x7e 0x01 0x00) followed by arbitrary data bytes; the parser enters STATE_DATA with rxlen=0, causing every subsequent byte to be written past the end of rxbuf until a framing or escape byte resets the state machine.

How to fix it

Apply the upstream fix that routes zero-length frames directly to STATE_TRAILER instead of STATE_DATA; rebuild and deploy the corrected kernel on all affected systems; where immediate patching is impossible, restrict attachment of the N_MCTP line discipline to trusted processes only.

How to confirm the fix worked

Confirm the kernel source contains the updated mctp_serial_push_header logic that sends zero-length frames to STATE_TRAILER; re-test with the KASAN-triggering frame sequence to ensure no out-of-bounds write occurs; verify netdev creation and frame handling logs show rejection of zero-length frames at the MCTP core.

Typical attack path

  1. Obtain CAP_NET_ADMIN to attach N_MCTP line discipline to target tty
  2. Bring the resulting mctpserialN netdev up
  3. Transmit zero-length frame header followed by arbitrary data bytes over the serial link
  4. Trigger continued writes that overflow the 74-byte rxbuf until framing byte resets parser
  5. Leverage resulting heap corruption for further exploitation or denial of service

How to detect it

Search kernel logs and dmesg for KASAN or UBSAN messages mentioning mctp_serial_tty_receive_buf or array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c; inspect tty receive paths and netdev creation events for unexpected MCTP serial interfaces; correlate serial traffic containing 0x7e 0x01 0x00 sequences followed by long data runs.

  • UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c
  • BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf
  • mctp_serial_tty_receive_buf
  • alloc_netdev_mqs mctp_serial_open

What your security team should do

  • Prioritize kernel updates for any system exposing serial interfaces that may carry MCTP traffic
  • Audit configurations for unnecessary N_MCTP line discipline usage and remove where possible
  • Monitor kernel logs for KASAN or UBSAN reports referencing mctp-serial.c
  • Apply least-privilege controls around CAP_NET_ADMIN for tty configuration

The record

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 > MCTP_SERIAL_FRAME_MTU) { dev->rxstate = STATE_ERR; } else { dev->rxlen = c; dev->rxpos = 0; dev->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->rxbuf[dev->rxpos] = c; dev->rxpos++; dev->rxstate = STATE_DATA; if (dev->rxpos == dev->rxlen) { dev->rxpos = 0; dev->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 still consumed, and the frame resolves to a zero-length skb that the MCTP core rejects; the parser never enters STATE_DATA with rxlen == 0, so the out-of-bounds write can no longer occur. KASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this change): UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370 index 74 is out of range for type 'u8 [74]' BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf Write of size 1 at addr ... by task kworker/u16:0 mctp_serial_tty_receive_buf tty_ldisc_receive_buf flush_to_ldisc Allocated by task 152: alloc_netdev_mqs mctp_serial_open v2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so the trailer/framing bytes are still consumed (Jeremy Kerr). Found by 0sec automated security-research tooling (https://0sec.ai).

Affected packages

Ecosystem Package Introduced Fixed