CVE-2026-72144

This CVE exposes a structural weakness in how kernel drivers manage multi-resource initialization: the manual cleanup model. The dell_init() function acquires resources in sequence — rfkill, LEDs, battery hook, debugfs, notifier — and returns errors if any step fails. The problem is that error paths require manually unwinding everything that succeeded, in reverse order, with precise knowledge of what was acquired at each stage. This is a cognitive burden that erodes under time pressure and code evolution. When a developer adds a new resource registration later — say, touchpad LED or keyboard backlight — they typically add the registration code and update the main error path. What gets forgotten are the nested error paths where some resources already succeeded but others failed. The cleanup code for those intermediate states is rarely tested because the error path itself rarely triggers in practice. On a specific Dell laptop model, the conditions that would cause one of these registrations to fail likely never occurred during development or testing, so the incomplete cleanup sat dormant. The fix is mechanically simple: five lines adding cleanup calls to the error paths that were missing them. But the real issue is that the kernel ecosystem has known solutions to this class of bug — devm_* resource management provides automatic rollback on failure — yet adoption is inconsistent. The kernel's culture resists abstraction layers that obscure control flow, and devm_* doesn't uniformly cover optional resources that might fail mid-initialization while later init continues. The result is that this bug class keeps recurring across drivers, each time patched with the same mechanical cleanup additions. For defenders: check your drivers for init functions that register multiple resources sequentially. Verify that every error path cleans up all resources acquired before the point of failure — not just the first error path, but every branching error path. The code that runs when things go wrong is the code that's tested least and matters most. Prioritize static analysis rules that flag unbalanced resource acquisition in error paths, or consider migrating to devm_* patterns where feasible.

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