CVE-2026-68124

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

mctpserialpush_header() case 2 and validates it upper-bound-only:

if (c > MCTPSERIALFRAME_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 STATEDATA. In mctpserialpush() STATEDATA, 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 CAPNETADMIN 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 mctpserialttyreceivebuf

  Write of size 1 at addr ... by task kworker/u16:0

   mctpserialttyreceivebuf

   ttyldiscreceive_buf

   flushtoldisc

  Allocated by task 152:

   allocnetdevmqs

   mctpserialopen

v2: route zero-length frames to STATETRAILER instead of STATEERR so

    the trailer/framing bytes are still consumed (Jeremy Kerr).

Found by 0sec automated security-research tooling (https://0sec.ai).