The vulnerability in cpuhp_invoke_callback() isn't a careless typo — it's a structural failure where the same variable (ret) holds two semantically different values depending on which code path executes. In the normal path, ret captures the original error from a failing hotplug callback. In the rollback path, it gets silently overwritten with the result of undoing earlier successful callbacks. Callers receive success even when the operation failed, because the rollback result overwrote the error signal they depend on.
This is where cognitive load becomes a security issue. Hotplug rollback code is low-frequency and high-complexity — written once under pressure, reviewed in isolation, then ignored for years. The pattern is familiar enough that reviewers see "error handling exists" without interrogating whether the error being returned is the one that matters. The code looks correct locally. It's semantically wrong globally.
The fix is trivial in implementation: preserve the original error separately from the rollback result. But the fix creates a new surface area — now two error-adjacent integers (orig_ret and ret) coexist in scope, and the pattern becomes renewable rather than eliminated. More critically, long-lived codebases domesticate bugs. Downstream subsystems have likely written compensating logic — retry heuristics, health checks, error pattern assumptions — that depends on the broken signal. The fix may break that compensating logic, and the regressions will look like the fix is wrong rather than that the workaround was wrong.
For defenders: audit any subsystem downstream of cpuhp_invoke_callback() that makes state decisions based on its return value. Check whether NUMA migration, scheduler load balancing, or interrupt routing code has grown defensive behavior around hotplug failures. Before deploying the patch, verify that compensating logic doesn't assume the bug's behavior — or accept that you'll need to update that compensating logic as part of the fix.
The EPSS score of 0.00176 reflects low mass-exploitability, not low impact. Kernel hotplug bugs aren't weaponized in ways honeypots catch — they're used for persistence in targeted scenarios. The real blast radius is state confusion: hardware left in undefined states, silent failures in dependent subsystems, and corrupted forensic records. Score low, but don't mistake that for risk low.