CVE-2026-68320

CVE-2026-68320 is a 4-byte stack buffer overflow in the Linux kernel's SCTP implementation, but the bug is a symptom of something more systemic: a semantic coupling between two constants that should never have been independent but had no mechanism to stay aligned. SCTP_NUM_CHUNK_TYPES (the protocol's type space, 20 entries) governs validation logic, while SCTP_AUTH_MAX_CHUNKS (the memory model's capacity, 16 entries) governs the destination buffer for chunk copying. These two constants live in different definition contexts, are reviewed in different patches, and were never traced end-to-end through the data path. The result is that validation accepts 20 chunks, but the destination buffer only holds 16 — overflowing by 4 bytes in kernel stack context. The fix confirms which constraint was authoritative: the validation was capped downward to 16, meaning the cookie serialization path's buffer size was always the real limit. The validation logic was written without tracing the allocation path — a cognitive framing problem where developers reach for the protocol-facing constant (documented, salient, RFC-referenced) rather than the allocation-facing constant (an implementation detail visible only through data-flow tracing). This is not a one-off mistake; it's a recurring genotype in kernel vulnerability history, appearing in timer subsystems, credential arrays, and netfilter hook limits across kernel versions. Exploitability assessments that focus on 'small overflow' miss the point. In kernel context, 4 bytes sits adjacent to saved registers and can corrupt pointers dereferenced in subsequent calls. The absence of observed crashes is not evidence of safety — it reflects that particular stack layouts didn't put critical data in the overflow zone, which varies across versions, architectures, and compiler optimizations. More concerning is the downstream blast radius: SCTP auth chunks touch the cookie mechanism, which crosses the user/kernel boundary during association setup. Any adjacent kernel structure becomes a collateral concern if an attacker manipulates chunk composition through SCTP socket operations. The fix itself carries hidden cost. It silently discards 4 protocol-valid chunk types at runtime with no logging, no warnings, and no indication to userspace that the SCTP stack is now operating in an RFC-divergent mode. Future developers tracing SCTP_AUTH_MAX_CHUNKS will find 16 and assume it's the canonical limit — the institutional knowledge that the protocol defines 20 is lost. The semantic coupling isn't just broken in code; it's broken in documentation. Audit priority: examine whether other SCTP parameter limits are defined in one context but misapplied elsewhere in association initialization. More broadly, treat this as a pattern trigger — wherever protocol-surface constants are used for safety validation without tracing to allocation constants, the code is latently wrong. The kernel's constant-definition discipline has no mechanism to enforce semantic relationships across subsystem boundaries, and this CVE is the latest evidence of that structural gap.

Reviewed through automated stages and approved by a human before publication.