For CVE-2026-74461 in the i2c imx driver, the EPSS score of 0.00138 is doing more analytical work than the CVSS of 8.4. Resist the reflex to treat this as an emergency patch based on severity alone.
The vulnerability is a race condition during i2c slave mode unregistration. The sequence requires a precise and narrow temporal window: an interrupt must fire after interrupts are disabled but before the slave pointer is cleared, the hrtimer must be pending in that exact interval, and the system must be actively using i2c slave mode at the moment of unregistration. This is not a condition an attacker can reliably engineer remotely—it requires either local access or extraordinary timing luck in a scenario where slave mode is already configured. The race window is measured in microseconds.
The fix is straightforward: cancel the hrtimer, wait for completion, then clear the pointer. This tells us the root cause was a simple ordering error, not a deep architectural flaw. The CVSS of 8.4 reflects the potential severity of a successfully triggered use-after-free in kernel space, which is fair—but severity scores don't capture exploitability conditions. The EPSS is telling you that exploitation probability is genuinely low in the wild, likely because i2c slave mode is not a common configuration on most systems and because the timing window is vanishingly small.
Prioritization guidance: weight this against your system's configuration. If the system does not use i2c slave mode, this vulnerability is effectively not applicable—the attack surface doesn't exist. If slave mode is in use, evaluate whether the system is exposed to local attackers or high-privilege adversaries who might attempt timing-based triggers. On systems without slave mode enabled, this can wait for the next regular kernel update cycle rather than triggering emergency patching.
The 2026 CVE date is notable. Assigning a CVE with a future-dated identifier typically indicates discovery through code audit rather than crash reports or anomalous behavior. This supports the low EPSS assessment—there was no exploitation signal driving the find.
One more thing: this appears to be a pattern vulnerability rather than an isolated instance. The same hrtimer cleanup ordering issue has surfaced in other kernel subsystems. The correct teardown sequence—cancel, wait for completion, then clear—has been documented since at least 2013, yet the pattern keeps appearing in drivers. This suggests a broader class of similar vulnerabilities may exist in other i2c controller drivers with slave mode teardown sequences. Treat this CVE as a signal to audit similar code paths in your kernel tree rather than a one-off incident.