CVE-2026-72488

The CVE-2026-72488 off-by-one in the Linux soundwire subsystem is a for-loop using `i <= num` instead of `i < num`, causing an out-of-bounds array access when the index equals the array length. Syzkaller caught it post-commit, which tells you something important: fuzzing excels at finding these bugs but arrives too late to prevent them. The deeper problem this CVE exposes is that simple arithmetic boundary errors systematically evade both human review and static analysis. Loop-boundary comparisons live in a cognitive blind spot during code review — reviewers focus on semantics, design, and API correctness, not the mechanical `<` versus `<=` distinction that was written in three seconds of boilerplate iteration code. Static analysis tools like Coverity or sparse require either expensive symbolic execution or explicit annotation overhead that developers rarely invest in routine loops. The result: off-by-one errors persist with disturbing frequency despite thousands of eyes on the codebase. The fix pattern — checking for existing entries before adding — actually introduces a different failure mode. It shifts from a deterministic out-of-bounds write to a potential double-add if the check itself has a race condition. That's not obviously safer, just differently dangerous. This pattern change should concern you: remediation paths carry ergonomic risk that the original bug analysis doesn't capture. What you should do: audit your codebases for loops over externally-controlled bounds where the comparison operator was not explicitly justified with a comment or assertion. The kernel lacks a cultural norm that loop bounds over external data require semantic documentation — you should establish that norm locally. Any refactoring that touches a loop comparison operator in functions receiving computed array lengths as parameters should require an explicit invariant comment explaining why the boundary changed. Without that documentation, the next developer will "simplify" `i < num` to `i <= num` the way they reformat whitespace, believing they're improving rather than weakening correctness. This vulnerability class has been documented since at least 2014. Each instance treated as a one-off allows the pattern to persist. Your intervention point is write-time verification — making loop boundaries self-documenting so that changes trigger review scrutiny rather than being absorbed as mechanical syntax.

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