GHSA-C8WC-V527-8F9G
Vulnerability from github – Published: 2026-08-10 15:33 – Updated: 2026-08-19 18:32In 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": [],
"aliases": [
"CVE-2026-68124"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-10T13:19:57Z",
"severity": "CRITICAL"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmctp: serial: handle zero-length frames to prevent rx buffer overflow\n\nThe MCTP serial receive state machine reads a frame length byte in\nmctp_serial_push_header() case 2 and validates it upper-bound-only:\n\n\tif (c \u003e MCTP_SERIAL_FRAME_MTU) {\n\t\tdev-\u003erxstate = STATE_ERR;\n\t} else {\n\t\tdev-\u003erxlen = c;\n\t\tdev-\u003erxpos = 0;\n\t\tdev-\u003erxstate = STATE_DATA;\n\t\t...\n\t}\n\nA length of zero passes this check, so rxlen is set to 0 and the state\nmachine advances to STATE_DATA. In mctp_serial_push() STATE_DATA, the\nincoming byte is stored and rxpos incremented before the terminator is\n\n\tdev-\u003erxbuf[dev-\u003erxpos] = c;\n\tdev-\u003erxpos++;\n\tdev-\u003erxstate = STATE_DATA;\n\tif (dev-\u003erxpos == dev-\u003erxlen) {\n\t\tdev-\u003erxpos = 0;\n\t\tdev-\u003erxstate = STATE_TRAILER;\n\t}\n\nWith rxlen == 0 the \"rxpos == rxlen\" terminator can never fire (rxpos is\nalready 1 on the first data byte), so subsequent bytes are written past\nthe end of the fixed 74-byte rxbuf, which is the last member of the\nnetdev private area. Every following data byte is an attacker-controlled\n1-byte out-of-bounds heap write, and the overflow continues until a\nframe (0x7e) or escape byte resets the parser -- effectively unbounded.\n\nReaching this requires CAP_NET_ADMIN to attach the N_MCTP line\ndiscipline and bring the resulting mctpserialN netdev up, after which\nthe bytes arrive via the tty receive path.\n\nRoute a zero-length frame straight to STATE_TRAILER instead of\nSTATE_DATA. The trailer/framing bytes are still consumed, and the frame\nresolves to a zero-length skb that the MCTP core rejects; the parser\nnever enters STATE_DATA with rxlen == 0, so the out-of-bounds write can\nno longer occur.\n\nKASAN, on a frame of 0x7e 0x01 0x00 followed by data bytes (before this\nchange):\n\n UBSAN: array-index-out-of-bounds in drivers/net/mctp/mctp-serial.c:370\n index 74 is out of range for type \u0027u8 [74]\u0027\n BUG: KASAN: slab-out-of-bounds in mctp_serial_tty_receive_buf\n Write of size 1 at addr ... by task kworker/u16:0\n mctp_serial_tty_receive_buf\n tty_ldisc_receive_buf\n flush_to_ldisc\n Allocated by task 152:\n alloc_netdev_mqs\n mctp_serial_open\n\nv2: route zero-length frames to STATE_TRAILER instead of STATE_ERR so\n the trailer/framing bytes are still consumed (Jeremy Kerr).\n\nFound by 0sec automated security-research tooling (https://0sec.ai).",
"id": "GHSA-c8wc-v527-8f9g",
"modified": "2026-08-19T18:32:05Z",
"published": "2026-08-10T15:33:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68124"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/06a6b606129c8a25cd457760f5370f3ff01fe05d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36dc6d6964a3b90411cc7944cd9b8b6f67b9807b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/64b96ae7912244d55257aa330d9569ee0a8f8d99"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/68819427bc07eca7963a9e8be19e5272cc29186c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/793b9b729f1e8de57be8c8daf1a9838be96cabed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f80ba170d7b3a44e3d244a2c8e06031d61bf3b23"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.