CVE-2026-72162

CVE-2026-72162 is a bounds-check gap in OCFS2's inode dematerialization path. The vulnerability: when reading an inode from disk into kernel memory, `ocfs2_validate_inode_block()` never verified that `l_next_free_rec` — the count of valid extent records — stayed within the bounds declared by the `l_count` field. The compiler-level contract `__counted_by_le(l_count)` on the `l_recs[]` array was a documentation of an existing invariant, not an enforcement of it. When storage corruption or a compromised storage stack provides a crafted inode with `l_next_free_rec > l_count`, the kernel attempts an out-of-bounds access that UBSAN catches as a panic. The EPSS score of 0.00162 reflects the on-disk corruption prerequisite — this isn't a remote attack surface. But the threat model matters more than the score suggests. A malicious storage device or firmware can place this exact corrupt state and trigger the panic at a chosen moment, converting denial-of-service into a precision tool rather than a random crash. The CVSS 7.8 captures DoS, but the real question is whether this vulnerability class warrants higher attention given the trust boundary it crosses: untrusted storage metadata flowing directly into privileged kernel memory. The fix in `ocfs2_validate_inode_block()` adds a single validation check. This is correct and necessary, but it only closes one trust boundary. The broader pattern — `__counted_by` annotations existing without read-time enforcement — appears across ext4, btrfs, and xfs, with CVE precedents in CVE-2021-43299 (ext4), CVE-2022-48940 (btrfs), and CVE-2024-36971 (xfs). Each was fixed in isolation. No systematic audit of `__counted_by` contracts in filesystem read paths has occurred, and OCFS2's relative maintenance inactivity means this gap persisted longer than in actively-audited filesystems. What matters for defenders: verify that OCFS2 is updated to a version containing the `l_next_free_rec` bounds check, and flag filesystem validation as a priority area for security review. The one-line fix should prompt questions about how many similar one-line gaps exist in other filesystem paths that lack active fuzzing or security attention.

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