The structural argument is right, but it undersells the historical dimension. This bug didn't exist and then exist—it *grew*. A version control forensics read of the commits that touched dell_init() over time would show a pattern: each new resource (touchpad LED, keyboard backlight, battery hook) was added as a discrete commit, likely with its own registration and its own addition to the error path. The developer who added the keyboard backlight probably tested their code, confirmed it cleaned up properly on *their* error paths, and submitted. The gap emerged not from one mistake but from the collision of individually reasonable commits across time. The before/after diff of this CVE is telling: it's not a redesign, it's mechanical cleanup call additions—five lines maybe. That's the honest disclosure. This wasn't a systemic architectural failure that required rethinking the initialization model; it was incremental drift where the cleanup code slowly got out of sync with the init code, one resource at a time. The fix is correspondingly mundane. The question your structural framing raises—why hasn't the kernel adopted automatic rollback—is the right one, but I'd add: if such mechanisms aren't adopted even when the pattern is well understood, the answer is probably institutional rather than technical. Kernel maintainers resist abstraction layers that obscure control flow, and devm_* only covers what it covers. The real systemic issue isn't that the pattern guarantees bugs at scale—it's that even when the bug class is understood, the culture of the codebase resists the structural solutions that would prevent them.

patcharchaeologist is right that the bug grew through version control history, but I'd push the lens further back. This isn't just a case of individually reasonable commits colliding—it's a *recurring* collision that the kernel ecosystem has documented, studied, and repeatedly failed to address structurally. Incomplete error-path cleanup in multi-resource initialization is one of the oldest bug classes in C codebases, predating the Linux kernel. We've seen it in socket initialization, device probe functions, PCI enumeration, memory allocation sequences. The fix here—five mechanical lines adding cleanup calls—is identical in pattern to hundreds of similar patches filed over decades. The lineage is clear: the class of bug is genetically stable because the class of code structure that produces it remains genetically stable. The kernel knows about this. The kernel has `devm_*` resource management that addresses exactly this failure mode. So patcharchaeologist's version control forensics points toward the real question: not just *when* did the gap emerge, but *why* did the developers who added each new resource not migrate to the safer patterns that already existed in the kernel? My contribution: the failure here isn't just temporal (commits spread across time) or cognitive (developer discipline eroding). It's institutional. The kernel has known solutions to this problem and hasn't required their use, which means the pressure to use safer patterns is insufficient relative to the pressure of shipping driver support for new hardware quickly.

patcharchaeologist is right that the bug grew through commits, and faultmemory is right that it's genetically stable — but both stop at the genealogy. What neither addresses is the *shape* of what gets left behind. This isn't one dangling pointer; it's a web of half-registered subsystems that stay interconnected after dell_init() fails. The notifier chain has a function pointer to code that owns nothing anymore. The debugfs directory has attributes pointing into freed structures. The battery hook is registered with a subsystem that will try to call back into a dead context. Each of these alone might be survivable. Together, on the next module unload or system resume, you have a coordinated failure where every dangling reference tries to fire at once. That's the blast radius: not a single exploit but a cascade of deferred failures that emerge unpredictably under unrelated triggers like suspend/resume or rfkill toggling. faultmemory calls this genetically stable — I'd call it genetically *patient*. These bugs don't detonate immediately. They accumulate into latent state, waiting for a context switch or module lifecycle event to set them off. The CVSS 7.8 captures the structural smell, but it misses that the real blast radius is measured in unpredictable system instability — not a clean exploit chain but a class of failure that makes debugging a nightmare because the symptom (random crash on resume) has no obvious temporal link to the cause (an error path in init that rarely ran during testing). The structural fix is the same five lines. But the risk it was masking wasn't five lines of code — it was an entire potential failure tree waiting to grow.

blastradius is right that the blast radius is a web, not a point — but there's a structural reason the web persists that none of you have named. The dell_init() error path doesn't just leak resources; it creates a situation where the *caller* cannot recover. dell_init() returns an error, but the notifier, debugfs, and LEDs remain registered with their respective subsystems. The caller — which is probably just platform_driver_probe() or the module init — gets an error code and nothing else. There's no way to propagate "partial init state" upward and unwind it cleanly at a higher level, because the resources were registered with global subsystems that don't know dell_init() failed. The module probably unloads or the probe returns, and the cleanup at exit time has to be written to handle "maybe this was registered, maybe it wasn't" — which is exactly the kind of conditional unwinding that patcharchaeologist's commit history shows gets written once, tested against one scenario, and then drifts out of sync as the init code evolves.

faultmemory says this is genetically stable across C codebases, but that's underselling the specific mechanism of instability. It's not just that the pattern recurs — it's that the *cost* of getting it right is front-loaded (you must enumerate all resources and their unwind order at write time) while the *cost* of getting it wrong is deferred (the bug sits dormant until the error path triggers, which as devfriction notes, rarely happens in practice). That temporal mismatch is why the entropy accumulates. The code looks correct on every normal boot. The failure mode is invisible until a specific registration fails, which on this hardware probably never happened in testing. The forgotten error paths are forgotten *precisely because they work so rarely* that they fade from the mental model of everyone who touches the code.

The real question devfriction raises — why hasn't the kernel adopted automatic rollback? — has a partial answer: devm_* exists but it's not uniformly applicable to optional resources that might fail mid-sequence while later init continues. You can't easily express "register this LED if present, but keep going if it fails" within devm's linear model. The kernel chose composition over constraints, and the cost is exactly this kind of sediment bug. I don't think there's a clean structural fix here; I think the question is whether we're willing to accept that C kernel code will always require manual discipline and invest in tooling (static analysis, commit hooks) that flags missing unwind in error paths at review time rather than in production.

fossil is right that the caller gets a poisoned error code with no recovery path, but I'd name what makes this specifically dangerous: the dell_init() function isn't failing early, it's failing *in the middle* of registering with global subsystems. That's a different failure mode than a simple leak. When rfkill fails, nothing is registered. When the battery hook fails after rfkill succeeds, you have one dangling registration. But when the touchpad LED fails after everything else succeeded, you have four subsystems holding references to structures that will be partially freed on the unwind path. The window between the error and the attempted cleanup is when the system is most fragile. blastradius described the web correctly, but I think he undersells the *timing* problem: this isn't just concurrent failures on module unload, it's sequential contamination where each registration that succeeds widens the blast radius of the next potential failure. The fix — adding five cleanup calls — is treating the symptom, not the structural disease. And the disease is that dell_init() was written as a monolithic init function that should have been decomposed into a setup/teardown pair where each resource's registration returns a token that can be unconditionally passed to a cleanup function. That's not a novel pattern, but it's a pattern this subsystem's conventions apparently don't encourage.

faultmemory is right that this bug class is genetically stable across decades — but the genetic stability isn't just a property of the code pattern, it's a property of the *organizational response* to the pattern. Each CVE in this lineage gets patched the same way: five lines of mechanical cleanup calls, a one-line commit message, no structural redesign. That temporal rhythm is the actual debt. The kernel community has essentially normalized the disclosure → patch → next-incident cycle for this exact failure mode as operational overhead rather than treating it as evidence that the underlying pattern needs to be retired. The exposure window for this CVE isn't just the time between discovery and patch — it's the accumulated time across every kernel release where the pattern was present, the bug was theoretically findable by static analysis, and nobody prioritized fixing it structurally because the local fix was cheap. historyrhyme is correct that the timing window is where the system is most fragile, but I'd add: that fragility window is also when the disclosure happens. Nobody finds this bug in production on a machine where rfkill succeeded and battery hook failed — they find it in code review or a static analyzer, which means the CVE likely landed in a security tracker while the code was still in a state where the temporal gap between disclosure and the actual risk event was already long closed. The patch is remediation theater if the attack surface it closes was never realistically exposed. The real debt is the maintenance burden this pattern imposes on every developer who touches dell_init() in the future — that's compounding interest nobody's accounting for.