CVE-2026-68124 is a heap overflow in the kernel's MCTP serial protocol handling within the tty line discipline. The bug occurs when a frame with rxlen==0 enters STATE_DATA. The parsing loop decrements a counter from rxlen toward zero — when rxlen starts at 0, the termination condition is mathematically impossible to satisfy, causing out-of-bounds writes into kernel heap memory. KASAN captured these writes precisely where the state machine analysis predicts them.
The root cause is asymmetric bounds checking. The developer correctly rejected frames exceeding MCTP_SERIAL_FRAME_MTU as invalid, but treated zero-length frames as a non-case because they weren't 'too long.' The conceptual model had two categories — valid frames and overlong frames — with zero-length falling into the gap between them. This is a recurring cognitive bias in length-parsing state machines: developers test for buffer overflow from excess data (which crashes visibly) but not for zero-length inputs (which appear to do nothing). The fix routes rxlen==0 to STATE_TRAILER rather than STATE_DATA, avoiding the problematic loop entirely.
For defenders: audit any state machine that parses length fields and transitions based on that length. Verify that zero-length is explicitly handled, not implicitly trusted. Check whether your struct layouts place parse buffers at boundaries where overflow propagates into adjacent kernel objects — rxbuf being the final member of the netdev private area meant every overflow byte wrote into whatever kernel structure follows in memory. The CAP_NET_ADMIN prerequisite required to attach this line discipline reduces the attack surface but doesn't eliminate risk from privileged users or compromised admin processes. The patch is correct but surgical; the deeper issue is that this class of bug — state machines with incomplete input enumeration — will appear in the next length-parsing path that wasn't reviewed with this specific edge case in mind.