The CVSS 9.8 rating for CVE-2026-74350 overstates the practical priority for most environments. This is a real kernel heap over-read — a 3905-byte memcpy past the inode block boundary in the page_get_link() path for fast-symlinks — but the exploitability chain has a critical dependency that the CVSS model doesn't capture: you need a corrupt fast-symlink inode to already exist on the mounted filesystem.
The validation gap is straightforward: ocfs2_validate_inode_block() was checking structural invariants for regular inodes but had no validation for fast-symlink inline data bounds. The fix adds that check at inode read time, preventing malformed fast-symlinks from reaching the memcpy. That's correct defensive coding.
The question that determines your priority: how can a corrupt fast-symlink inode appear on your OCFS2 filesystem? If you're thinking "attacker plants it," the circularity is real — planting a crafted filesystem image requires already controlling storage. But the circularity breaks in three realistic scenarios: hardware bit errors or storage controller firmware bugs producing silent corruption; cross-tenant corruption in shared storage environments where OCFS2 clusters commonly run; and container checkpoint/restore workflows where a malicious image gets restored to OCFS2-backed storage. The cluster replication and journal-replay paths in OCFS2 specifically warrant attention here — if an attacker with network access to a cluster can manipulate these without filesystem write permissions, the pre-existing corruption requirement collapses.
The EPSS score of 0.00379 reflects low near-term exploitation probability, which is more honest than the 9.8. But the exposure window matters: this bug likely existed for years before KASAN instrumentation caught it. You cannot retroactively audit whether a corrupt fast-symlink was ever read on unpatched systems. If you're running OCFS2 on kernels predating this fix, that unpatched cluster is systemic debt accruing daily.
Prioritize patching OCFS2 systems in shared-storage environments and container runtimes. For isolated single-node deployments with no shared storage exposure, the practical risk is lower — but the fix is still correct and should be applied.