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).
Security readout for executives and security teams
Plain-English summary
A malformed zero-length MCTP serial frame can make an affected Linux kernel write beyond an allocated receive buffer, potentially causing crashes, corruption, or broader compromise. Exposure is limited to systems where a privileged actor can configure and activate the MCTP serial interface, so this is not described as a general internet-facing flaw.
Executive priority
Prioritize affected systems that use MCTP serial interfaces or delegate CAP_NET_ADMIN. Apply vendor kernel updates promptly because the memory corruption is severe, while recognizing that the documented prerequisite materially reduces exposure on systems without this configuration.
Technical view
The MCTP serial parser accepted a zero frame length and entered its data state. Because the completion condition could never be met, subsequent attacker-controlled bytes overflowed the fixed 74-byte receive buffer. The correction sends zero-length frames directly to trailer processing, preventing entry into the vulnerable state.
Likely exposure
Likely exposure is concentrated in affected Linux systems using, or capable of enabling, MCTP over serial. Reaching the vulnerable receive path requires CAP_NET_ADMIN to attach the N_MCTP line discipline and bring up the resulting network device. Exact distribution package exposure requires vendor mapping.
Exploitation context
The supplied record is not in KEV and provides no evidence of active exploitation. It documents an automated discovery and KASAN-confirmed out-of-bounds heap write. Exploitation requires privileged interface setup, but malicious serial input can then reach the vulnerable parser.
Researcher notes
KASAN and UBSAN confirmed an out-of-bounds write after the parser accepted a zero length. The overflow could continue until framing reset the parser. The bundle identifies upstream stable commits but does not provide distribution-specific package mappings, public proof-of-concept status, or confirmed exploitation.
Mitigation direction
Update to a vendor-supported kernel containing the applicable stable fix.
Check Linux distribution advisories for corrected package versions and reboot requirements.
Avoid activating MCTP serial interfaces until affected systems are updated.
Restrict CAP_NET_ADMIN assignments to trusted administrators and tightly controlled services.
Validation and detection
Inventory kernel versions on systems supporting MCTP serial communication.
Confirm whether N_MCTP and an mctpserial network device are configured or active.
Map distribution kernel packages to the cited upstream stable fixes.
Verify the running kernel after remediation, including any required reboot.
Review CAP_NET_ADMIN grants for users, containers, and services.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-68124 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
7Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.