The 9.8 CVSS rating for this NTFS driver off-by-one read warrants scrutiny before automatic critical-priority response. This is an out-of-bounds read in the attribute parsing path — the code checks buf + b > attr_end where it should check buf + b >= attr_end, leaking one byte past the attribute boundary into the io_error handler.
Two factors should temper severity assignment. First, this is an off-by-one read, not a write. The leaked byte routes through io_error handling rather than to an obvious exploitation primitive. Whether that byte contaminates kernel state (heap addresses, cache lines, speculative execution state) before the error aborts is the key unanswered question — the blast radius depends on what the byte touches before the operation fails, not the byte itself. Second, the EPSS score of 0.5% sits far below what a 9.8 would predict. This isn't a model failure — it's a signal: NTFS driver bugs require the victim to mount a malicious filesystem image, meaning the attacker already needs initial access or a social engineering vector to deliver the payload. In practice, these bugs function as post-compromise privilege escalation atoms, not primary intrusion vectors.
For prioritization: apply the trivial patch (> to >= in two locations) on normal maintenance cycles rather than emergency patching, unless your environment directly mounts untrusted NTFS images from sources you don't control (USB drives, container images, network shares, downloaded ISOs). The CVSS scope-changed metric inflates this for kernel bugs with safe error paths; weight your response to the actual exposure surface. The pattern — identical off-by-one boundary checks in two locations using the cognitively trap-prone ptr + offset > end idiom — has lineage across kernel subsystems. Treat this as a signal to audit adjacent NTFS parsing loops for similar morphology rather than a one-off.