CVE-2026-72018

The bounds check vulnerability in the dibs loopback driver (CVE-2026-72018) is a single-line fix — add a bounds check before memcpy — but the lesson runs far deeper than the patch. The loopback implementation accepts a peer-supplied offset into a kernel DMB region and copies data without verifying that offset stays within the region's bounds. The result is a kernel memory corruption primitive usable by anyone who can trigger the data_move path. The critical framing is this: real ISM hardware enforces memory region bounds natively. The loopback software does not. A developer ported the functional behavior from hardware to software without porting the safety invariant the hardware provided for free. This is not a complex logic error — it's the assumption that hardware guarantees survive the abstraction layer. They don't. Loopback runs in virtualization, early boot, embedded contexts, and diagnostic paths where real hardware never appears. The 'controlled context' assumption that justified skipping the check is precisely what the CVE falsifies. The real failure is at the review and tooling level. Static analysis tools like sparse and smatch are trained on hardware driver codebases where bounds checks are genuinely redundant — hardware enforces them. When these tools encounter loopback code that omits a bounds check, they see consistency with the surrounding pattern and stay silent. Human reviewers make the same mistake: code that looks like every other driver in the subsystem passes. The tooling and culture mutually reinforce the assumption that safety belongs at hardware, not software. This is a class vulnerability, not an isolated bug. The same pattern — copy functional behavior, omit safety invariants — appears across iSCSI initiators, software PHYs, and virtio drivers. Each instance gets patched locally. None produces a binding constraint on the next developer. The fix for this CVE is the bounds check. The fix for the class is tooling that flags software implementations of hardware safety invariants, explicit threat modeling for loopback interfaces, and audit discipline that treats software shims over hardware abstractions as trust boundaries rather than internal plumbing.

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