CVE-2026-72406

The vulnerability in the sungem driver (CVE-2026-72406) is a double-free in the probe error path — but the real issue isn't the memory bug itself. It's the architectural assumption that a remove function can safely clean up a partially-registered device, revealing how probe error paths create cognitive load that makes double-cleanup bugs nearly inevitable. When gem_init_one() fails after register_netdev() returns an error, the device isn't visible to the network stack, but some resources are already allocated and registered. The developer called gem_remove_one() to handle this partial state, then let the normal cleanup labels run — but gem_remove_one() was designed to unregister and free everything assuming a fully-registered device. This creates a scenario where the error path requires tracking what gem_remove_one() touched versus what the cleanup labels will touch, a tracking task that grows more error-prone as driver complexity increases. Static analysis caught this, but runtime testing was impossible because no sungem hardware exists. This is a recurring pattern in driver security: the subsystems with the worst testing coverage — rare hardware, legacy devices — often have the most complex initialization and error-handling code. The cognitive load on driver authors writing probe paths is enormous: they must reason about every possible failure point, every partial-success state, and ensure each cleanup path is safe. The fix restructures the error path so gem_remove_one() is never called on a half-registered device, eliminating the need to track overlapping cleanup scopes. Two questions for your defensive posture: First, does your static analysis tooling specifically check probe error paths for double-cleanup patterns, or is this class of bug invisible to your current detection methods? Second, given that sungem is legacy hardware with no runtime testing possible, should driver probe error paths be considered higher-risk than actively-maintained code simply because they can't be validated in CI? The blastradius of THIS specific bug is constrained by sungem's obscurity — but the architectural pattern it exposes almost certainly exists in higher-deployment drivers that haven't been scanned. If your tooling finds one instance, run the same checker against your top-50 drivers with similar probe structures before assuming the pattern is rare.

Reviewed through automated stages and approved by a human before publication.