CVE-2026-68124: Linux Kernel Buffer Overflow Vulnerability

CVE-2026-68124 Overview

CVE-2026-68124 is a heap out-of-bounds write vulnerability in the Linux kernel's Management Component Transport Protocol (MCTP) serial driver (drivers/net/mctp/mctp-serial.c). The mctp_serial_push_header() function validates the frame length byte with an upper bound only, allowing a length of zero to pass validation. When rxlen is set to 0, the state machine advances to STATE_DATA and the terminator condition rxpos == rxlen can never fire because rxpos is already 1 after the first data byte is written. Subsequent bytes are written past the end of the fixed 74-byte rxbuf, producing attacker-controlled one-byte out-of-bounds heap writes that continue until a frame delimiter (0x7e) or escape byte resets the parser.

Critical Impact
An attacker with CAP_NET_ADMIN who can attach the N_MCTP line discipline and feed bytes into the tty receive path can trigger effectively unbounded one-byte heap writes adjacent to the netdev private area, enabling kernel memory corruption.

Affected Products

Linux kernel builds containing the MCTP serial driver (drivers/net/mctp/mctp-serial.c)
Distributions shipping the MCTP serial line discipline (N_MCTP)
Systems where userspace can obtain CAP_NET_ADMIN and access a tty device

Discovery Timeline

2026-08-10 - CVE-2026-68124 published to NVD
2026-08-13 - Last updated in NVD database
Reported as found by 0sec automated security-research tooling (0sec.ai)

Technical Details for CVE-2026-68124

Vulnerability Analysis

The MCTP serial receive state machine parses framed byte streams from a tty using a length-prefixed format. In mctp_serial_push_header() case 2, the driver reads a frame length byte c and validates only that it does not exceed MCTP_SERIAL_FRAME_MTU. It fails to reject a length of zero. With rxlen set to 0, the parser transitions to STATE_DATA.

In mctp_serial_push() under STATE_DATA, the driver stores the incoming byte at dev->rxbuf[dev->rxpos] and then increments rxpos. It checks for the trailer transition after the write, using the equality dev->rxpos == dev->rxlen. Because rxpos becomes 1 on the first data byte while rxlen remains 0, the equality never holds and the parser stays in STATE_DATA indefinitely.

Each subsequent byte writes one attacker-controlled value past the end of the 74-byte rxbuf. The buffer sits at the tail of the netdev private area, so overflow bytes land in adjacent heap memory. KASAN confirms the primitive with an array-index-out-of-bounds and slab-out-of-bounds write in mctp_serial_tty_receive_buf when feeding the sequence 0x7e 0x01 0x00 followed by data bytes.

Root Cause

The root cause is missing lower-bound validation on the parsed frame length combined with a post-increment terminator check. Zero is a semantically invalid frame length that the state machine treats as valid, producing an off-by-N heap out-of-bounds write [CWE-787] that is bounded only by the appearance of a framing or escape byte.

Attack Vector

Exploitation requires CAP_NET_ADMIN to attach the N_MCTP line discipline to a tty and bring the resulting mctpserialN netdev up. Once attached, any bytes delivered through the tty receive path — including from a local pty, a physical serial line, or an adjacent device speaking MCTP-over-serial — feed the vulnerable parser. The fix routes zero-length frames directly to STATE_TRAILER, causing the trailer bytes to be consumed and the resulting zero-length skb to be rejected by the MCTP core.

Detection Methods for CVE-2026-68124

Indicators of Compromise

KASAN reports of slab-out-of-bounds writes in mctp_serial_tty_receive_buf, tty_ldisc_receive_buf, or flush_to_ldisc
UBSAN array-index-out-of-bounds messages referencing drivers/net/mctp/mctp-serial.c and the u8 [74] rxbuf type
Unexpected mctpserialN network interfaces created on hosts that do not use MCTP
Processes invoking ioctl(TIOCSETD, N_MCTP) outside of legitimate BMC or platform-management tooling

Detection Strategies

Audit kernel logs for KASAN, UBSAN, or slab corruption reports referencing the MCTP serial code path
Monitor for CAP_NET_ADMIN-holding processes attaching non-standard line disciplines via TIOCSETD
Alert on creation of mctpserial* netdevs on systems whose baseline does not include MCTP

Monitoring Recommendations

Enable auditd rules for ioctl syscalls setting tty line disciplines and correlate against a known-good process baseline
Ingest kernel ring buffer messages into centralized logging and alert on KASAN or general protection fault signatures
Track loaded kernel modules and flag environments where mctp-serial loads unexpectedly

How to Mitigate CVE-2026-68124

Immediate Actions Required

Apply the upstream kernel fix that routes zero-length MCTP serial frames to STATE_TRAILER instead of STATE_DATA
Restrict CAP_NET_ADMIN to trusted service accounts and remove it from unprivileged workloads and containers
Blacklist the mctp-serial module on systems that do not require MCTP-over-serial

Patch Information

The fix is available in the stable kernel tree. See the following commits: Kernel commit 06a6b606, Kernel commit 36dc6d69, Kernel commit 68819427, Kernel commit 793b9b72, and Kernel commit f80ba170. The patch adds a check for zero-length frames in mctp_serial_push_header() and transitions the state machine to STATE_TRAILER, causing the MCTP core to drop the resulting zero-length skb.

Workarounds

Prevent loading of the mctp-serial driver by adding blacklist mctp-serial to /etc/modprobe.d/ on hosts that do not use MCTP
Remove CAP_NET_ADMIN from container and service profiles that do not require network administration
Restrict access to tty devices used for platform management to root-owned service accounts only

bash

# Configuration example: block the vulnerable driver until patched
echo 'blacklist mctp-serial' | sudo tee /etc/modprobe.d/disable-mctp-serial.conf
sudo rmmod mctp-serial 2>/dev/null || true
# Verify the module is not loaded
lsmod | grep mctp_serial