Skip to main content

Linux kernel CVE-2026-68124

| EUVDEUVD-2026-55505 CRITICAL
2026-08-10 Linux GHSA-c8wc-v527-8f9g
Critical
Disputed · 9.6 Vendor: Linux
Share

Severity by source

Sources disagree (Medium–Critical)
Vendor (Linux) PRIMARY
9.6 CRITICAL
AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
8.4 HIGH

Attacker must reach the serial/tty channel of a pre-configured MCTP interface (AV:L); the CAP_NET_ADMIN setup is a deployment precondition not attacker privilege (PR:N); unbounded kernel heap write yields full C/I/A impact.

3.1 AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
4.0 AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
SUSE
6.0 MEDIUM
AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

Attack Vector
Adjacent
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Aug 14, 2026 - 01:35 vuln.today
CVSS changed
Aug 13, 2026 - 23:37 NVD
9.6 (CRITICAL)
Patch available
Aug 10, 2026 - 14:18 EUVD
CVE Published
Aug 10, 2026 - 11:58 cve.org
CRITICAL 9.6
CVE Published
Aug 10, 2026 - 11:58 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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).

AnalysisAI

Kernel heap out-of-bounds write in the Linux MCTP serial driver (drivers/net/mctp/mctp-serial.c) lets an attacker on the serial/tty channel corrupt memory adjacent to the netdev private area on any host where an mctpserialN interface has been configured. The receive state machine accepts a zero-length frame, sets rxlen=0, and enters STATE_DATA, so the 'rxpos == rxlen' terminator never fires and every subsequent inbound byte becomes a 1-byte attacker-controlled OOB heap write past the fixed 74-byte rxbuf, continuing effectively unbounded until a frame or escape byte resets the parser. No public exploit is identified at time of analysis and EPSS is low (0.19%), but the flaw was reproduced with KASAN/UBSAN and carries high memory-corruption impact.

Technical ContextAI

Management Component Transport Protocol (MCTP) is a DMTF-standardized messaging protocol used mostly for platform/BMC management; the mctp-serial driver tunnels MCTP over an asynchronous serial (tty) link using an N_MCTP line discipline. The bug is in the byte-oriented receive parser: mctp_serial_push_header() validates the frame length byte only against an upper bound (MCTP_SERIAL_FRAME_MTU) and not against zero. rxbuf is a fixed u8[74] and is the last member of the netdev private allocation, so writes past it land in adjacent slab memory. This is a classic missing-lower-bound / off-by-design length-validation defect - a heap buffer overflow (CWE-787 Out-of-bounds Write, the CWE field is N/A in the source data) driven by an unchecked length field in a stateful parser.

RemediationAI

Apply the vendor-released patch by upgrading to a fixed stable kernel: 7.1.6, 6.18.42, 6.12.101, or 6.6.148 (fix also present in 7.2-rc5), corresponding to git.kernel.org/stable/c/68819427bc07, 06a6b606129c, 793b9b729f1e, f80ba170d7b3, and 36dc6d6964a3; the fix routes zero-length frames to STATE_TRAILER so the parser never enters STATE_DATA with rxlen==0. If you cannot patch immediately, reduce exposure by not loading/attaching the N_MCTP line discipline and not bringing mctpserialN interfaces up on hosts that do not require MCTP-over-serial (blacklisting the mctp-serial module removes the vulnerable path entirely, at the cost of losing MCTP serial functionality). Where MCTP serial is required, restrict who can perform CAP_NET_ADMIN configuration and physically/logically restrict access to the serial/tty endpoints feeding the interface, since the untrusted bytes arrive via the tty receive path; these controls limit but do not eliminate risk, so treat them as interim only.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

CVE-2026-68124 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy