CVE-2026-68124 mctp: serial: handle zero-length frames to prevent rx buffer overflow
A zero-length frame in the Linux kernel MCTP serial driver causes an out-of-bounds heap write, potentially allowing code execution or privilege escalation.
- Exploited in the wild
- Not known
- Login needed
- Not needed
- Attackable
- Local or same network only
- Victim action needed
- Not needed
- Fix
- Available
What is CVE-2026-68124?
CVE-2026-68124 is a critical memory corruption vulnerability in Linux, published on 10 Aug 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Official description
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).
Which versions are affected by CVE-2026-68124?
How do I fix CVE-2026-68124?
Apply the vendor's patch.
Upgrade to the fixed version. Memory-safe languages, compiler hardening and fuzzing prevent most new cases. More about Memory corruption.
Is CVE-2026-68124 being exploited?
There is no known exploitation of CVE-2026-68124 in the wild and no public exploit code.
Sources
Also known as BELL-CVE-2026-68124, DEBIAN-CVE-2026-68124, GHSA-c8wc-v527-8f9g, UBUNTU-CVE-2026-68124.