CVE-2026-68474

The CVSS score for CVE-2026-68474 is almost beside the point. What makes this vulnerability analytically revealing is that the correct fix already existed twice in the same source file — in `spufs_mem_mmap_fault()` and `spufs_ps_fault()`, both handling the same SPU hardware interface with proper offset clamping to `LS_SIZE` and length constraints. `spufs_mem_mmap_access()`, by contrast, checks its computed offset against `vma->vm_end` rather than the actual hardware buffer size. On 64-bit systems, `vma->vm_end` is architecturally always larger than any offset into local store, making this check a no-op. The offset flows through to the buffer access unconstrained. This isn't a regression in the traditional sense — it doesn't appear to be a 64-bit port that broke a previously correct guard. The more disturbing interpretation is that a developer wrote a third implementation alongside two correct ones and shipped it without cross-referencing. The correct pattern was sitting three functions away, visible to anyone who opened the file, and still the bug shipped. That points not to a single cognitive lapse but to a structural condition: code without active ownership becomes invisible during development. When someone touches adjacent code, they audit what's changing — not the dormant functions that aren't being modified. Static analysis tools could surface this pattern divergence, but they likely aren't running against this code path during merge reviews. SPUFS targets the Cell BE processor's Synergistic Processing Units — hardware end-of-life since approximately 2012. The subsystem has no active stakeholders because no one has the hardware. This is the real story: inert code accumulates subtle inconsistencies until external disclosure forces attention. The severity weighting reflects this obsolescence. EPSS scores this at 0.00164, and for good reason — any system still running SPUFS code is almost certainly on heavily patched or legacy kernels. The practical attack surface is negligible. However, there's a deeper concern that the patch doesn't address. The existence of divergent bounds enforcement across three sibling functions creates a combined attack surface that exceeds any single vulnerability. If `spufs_mem_mmap_access()` is now fixed but its siblings haven't been adversarially tested under modern heap manipulation techniques, we're propagating whatever behavior happened to survive neglect rather than validating it under current threat models. The correct pattern existed in the file — the question is whether it was ever correct under real attack conditions, or merely correct by accident of never being exercised. For defenders: patch this function, yes, but also audit the entire subsystem for similar boundary-check inconsistencies. Check whether other deprecated hardware subsystems have the same pattern of divergent guards across sibling implementations. The absence of active ownership doesn't mean the code is secure — it means the code hasn't been examined, and that examination is long overdue.

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