The CVSS 7.8 on this Linux kernel use-after-free in the Intel AMT driver warrants scrutiny, not panic. The EPSS score of 0.00134 tells you something the severity score alone doesn't: this vulnerability is structurally unlikely to be exploited in the wild.
The bug is a classic work-queue race. The amt_dev_stop() function uses cancel_delayed_work_sync() to halt deferred work during device teardown, but this only cancels work already queued at call time — if event_wq reschedules req_wq after cancellation, the work executes against freed memory. The fix switches to disable_delayed_work_sync(), which prevents future rescheduling entirely. This is the correct semantic for device teardown and matches patterns seen in prior work-queue UAFs across the kernel.
What matters operationally is the attack surface gap. AMT (Intel Active Management Technology) is enterprise vPro hardware functionality — typically present only on business-class servers and workstations, and often disabled. The race window requires triggering amt_dev_stop() while simultaneously manipulating event_wq, which demands local access and precise timing. This isn't a remote-friendly bug; it's a narrow, timing-dependent condition on specialized hardware.
The practical implication: patch this in your kernel update queue, but don't treat it as emergency triage. Prioritize systems where AMT is actually enabled — enterprise servers undergoing hot-swap maintenance, driver updates, or VM migration are the contexts where this UAF could trigger a kernel crash during legitimate operations. On desktop or embedded systems without AMT, this sits in the kernel source but never executes the vulnerable code path.
The systemic pattern worth watching: this is the Nth instance of work-queue teardown UAFs in kernel drivers. Each CVE gets individually scored and patched, but the 47 other driver work-queue teardown paths in the kernel don't get audited as a batch. The EPSS staying low reflects institutional learning — the kernel's modular isolation reliably contains this class of failure. That's useful context for similar future CVEs: when you see high CVSS, low EPSS on a specialized kernel subsystem, the gap is telling you something about where your attention should go.