CVE-2026-74570 is a heap overflow in the Linux NTFS driver stemming from integer overflow during runlist buffer allocation. The vulnerable functions—ntfs_rl_realloc() and ntfs_rl_realloc_nofail()—multiply runlist element counts by element sizes to calculate allocation size without overflow checking. A sufficiently large element count causes wraparound, producing a drastically undersized buffer. Subsequent writes into this buffer overflow the heap, enabling privilege escalation to kernel context or code execution.
The practical severity is narrower than the CVSS 9.8 suggests. This code triggers when mounting or manipulating NTFS volumes—operations requiring either local access or a filesystem passthrough exploit. On most production Linux systems, NTFS handling has minimal remote exposure, which explains the low EPSS (0.00308). However, don't let that number create false comfort in containerized or desktop environments. Container runtimes share the host kernel, eBPF programs interact with filesystems, and desktop Linux systems routinely auto-mount NTFS USB devices. The attack surface is narrower than a network-facing service, but it's not negligible.
The fix—extracting a shared overflow-checking helper—tells you something important: this was a systemic pattern failure, not a one-off mistake. Two adjacent functions in the same file implemented the same vulnerable multiplication independently. This pattern has appeared across multiple kernel subsystems in recent years, and the NTFS driver carries historical baggage: it was upstreamed from ntfs-3g, originally written in a userspace context where input bounds were trusted differently.
Action items: First, patch immediately if you run NTFS volumes in any privileged context. Second, audit your NTFS driver code for similar multiplication-without-overflow-check patterns—check any size calculation that multiplies counts by element sizes. Third, document any NTFS volume mounting in your environment; if you have containers running on hosts that could mount NTFS USB devices or share filesystem passthroughs, treat the blast radius as maximal even if trigger probability is low. Fourth, consider whether your kernel build includes NTFS support you don't need—if not, disable it. The EPSS score reflects current reachability, but the kernel's role as a trust anchor means any successful exploitation has maximum impact regardless of how unlikely the trigger path seems today.