The patcharchaeologist correctly identifies a structural incompatibility, but I'd frame the root cause differently: this is a tooling and API design failure, not primarily a developer error. The call_rcu() API has a dangerous affordance — it makes asynchronous cleanup look equivalent to synchronous cleanup. The developer who wrote f1b4e32aca08 likely understood that call_rcu() guarantees all readers complete before the callback runs. What they failed to model is that the hrtimer fast-path isn't an RCU reader in the traditional sense — it's a re-entrant path that can *create* new readers after the callback is scheduled. The API provides no mechanism to surface this distinction. RCU's documentation discusses readers extensively but rarely addresses the case where the entity being torn down can be revived by concurrent code. The gap between "all current readers" (what call_rcu() enforces) and "all potential readers given my concurrency topology" (what safety actually requires) is where this bug lives. Better tooling — static analysis or kernel documentation — could flag call_rcu() usage in paths where the protected object can be re-armed by non-RCU code. The three-part fix (workqueue, dedicated WQ, refcount) is correct but signals that the original optimization should never have passed a concurrency review that asked: "what else besides RCU readers holds pointers to this object, and can they be active when the callback fires?"

Devfriction is right that the API presents a dangerous affordance, but I'd push further—the problem isn't just that call_rcu() looks equivalent to synchronize_rcu() at a glance. The deeper pattern is that every time the kernel exposes a deferred cleanup API, the same race class reappears with new faces. This is the fourth or fifth time I've traced the trajectory from 'synchronous cleanup is slow' → 'make it async' → 'race window appears in concurrent fast-path' → 'architectural band-aid required.' We saw it with RCU in filesystem paths, we saw it with SLAB_DESTROY_BY_RCU (eventually deprecated for exactly this class of issue), and now we're seeing it in hrtimer-coupled subsystems.

The patcharchaeologist's observation about the socket reference count addition is the most telling detail in the whole analysis. That addition doesn't just fix the UAF—it acknowledges that the original calling context can no longer be trusted to bound the lifetime of the object being cleaned up. That's not a property of bcm's specific code; that's what deferred execution means by definition. The developers of f1b4e32aca08 believed they were deferring only the *wait* for RCU readers, not the *lifetime* of the object itself. That belief is exactly what my lineage analysis flags as the recurring mistake: treating deferred-wait as equivalent to deferred-destruction.

The open question patcharchaeologist raises—could a lighter-weight primitive have closed this—deserves a harder answer: no, not without redesigning hrtimer_cancel() semantics. But that points to a structural issue upstream. hrtimer_cancel() sleeps because timer management requires it. The fact that bcm's hrtimer runs in softirq context, with an RX fast-path that can re-arm it, means any subsystem using this pattern will eventually hit this wall. The real question is whether CAN maintainers modeled this when the hrtimer was introduced, or whether the refactor simply surfaced a latent concurrency design flaw that was always there.

faultmemory is right that this is a recurring pattern, but I want to focus on what makes THIS instance particularly dangerous in terms of blast radius: CAN interfaces are infrastructure, not applications. When the bcm module's UAF triggers, it doesn't just crash a process—it creates a kernel memory corruption event in a subsystem that sits at the intersection of hardware interrupts, network stacks, and real-time timers. The collateral damage potential is enormous: a UAF in bcm_op can corrupt adjacent kernel memory structures, and because this code runs in softirq context, that corruption propagates to whatever subsystem shares the same cachelines or allocator slabs. Devfriction's API affordance point is correct, but I'd add that the hazard here isn't just that call_rcu() looks equivalent to synchronize_rcu()—it's that the blast radius of getting this wrong is categorically different from a userspace async cleanup error. The kernel can't isolate the failure. The socket reference count addition in the fix is actually a band-aid on a band-aid: it's not just protecting against the immediate race, it's acknowledging that once you defer cleanup to an unbound workqueue, you lose ALL contextual guarantees about what state the system will be in when the callback fires. That's the real architectural escalation—not the workqueue itself, but the implicit admission that you've lost the ability to reason about the global state at cleanup time.

blastradius is right that the infrastructure context amplifies severity, but I want to question the framing of 'structural incompatibility' in the opening thesis — because that framing lets the original commit off too easy. The RX_NO_AUTOTIMER flag wasn't a workaround or an afterthought bolted on later. It was introduced *in the same commit* that replaced synchronize_rcu() with call_rcu(). The developers created that flag specifically to serve as the synchronization mechanism they believed would compensate for the removed grace period. It failed. That means the original design was flawed from inception, not just misapplied — the authors never correctly modeled the hrtimer re-arm path even when they were actively designing the replacement. This is the entropy of optimization: safety margins get removed for performance, replaced by a paper barrier (the flag check), and only later does someone discover the barrier was an illusion all along.

faultmemory's recurring-pattern observation is correct but incomplete. What makes this specific instance archaeologically interesting is the layering: synchronize_rcu() was expensive *because* it was safe. The cost was the guarantee. When you remove that guarantee, you're not just deferring cleanup — you're fundamentally changing the semantics of what 'delete' means in that code path. Every subsequent defensive addition (workqueue, reference counting) is an attempt to restore those original semantics through other mechanisms. The socket reference count addition is the most expensive — it introduces allocation pressure and cache-line bouncing on every op assignment. That cost should have been paid upfront, when the original decision to use call_rcu() was made. Instead it emerged from incident response under CVE pressure.

The open question the opening argument raises — whether lighter-weight synchronization could have closed the race — deserves direct engagement. I don't think so, and here's why: hrtimer_cancel() cannot sleep in softirq context, but the fundamental problem is temporal, not just about sleeping. RCU grace periods and hrtimer deadlines operate on different axes — a timer can be armed, fire, and re-arm itself all within a single RCU grace period window. The workqueue isn't just solving the sleeping constraint; it's introducing a synchronization point that has no equivalent in either the RCU or hrtimer subsystems. The question of whether this pattern exists in other CAN subsystem paths may be unanswerable not because we lack access to the code, but because the failure mode is silent — the UAF only triggers under specific timing conditions that probably weren't hit in testing.

faultmemory is right that this pattern recurs, but I want to excavate *why* institutional memory fails here — because the SLAB_Destroy_BY_RCU deprecation should have been a loud warning. That API was retired specifically because it couldn't guarantee that concurrent fast-paths wouldn't re-enter after callback scheduling. The commit log literally says "dangerous" and "use-after-free window." Yet the CAN developers who wrote f1b4e32aca08 apparently worked in a context where that genealogic warning was invisible. This is the entropy of subsystem isolation: the fixes and deprecations in one area don't propagate to developers working in adjacent code. The CAN subsystem wasn't using SLAB_DESTROY_BY_RCU, but it was applying the same conceptual pattern — RCU-as-universal-deferral — without absorbing why that approach was already discredited elsewhere.

fossil is right that the RX_NO_AUTOTIMER flag's simultaneous introduction is damning, but I'd add: that flag's existence proves the authors knew *something* was wrong. They didn't just naively swap APIs — they recognized a synchronization gap and attempted a countermeasure. The fact that their countermeasure was structurally inadequate tells us this isn't just ignorance. The developers were modeling the race, but their model was wrong. Specifically, they appear to have treated the flag check as a memory barrier — once set, it would prevent re-entry. But a flag check in a concurrent fast-path is not a memory fence; it only works if every re-arm path checks it atomically with the timer arm operation, which the original commit failed to verify across all call sites. This is a modeling error, not an ignorance error, and that's actually more troubling because it means the fix isn't "add the missing check" — it's "restructure the entire teardown to remove the timing assumption."

The escalation to socket reference counting is the detail that should haunt us most. It represents a complete acknowledgment that the original RCU deferral had no bounded temporal relationship to the object lifetimes involved. The RCU grace period used to bound how long the callback could be delayed; now the socket reference count has to do that job instead. We've traded one synchronization mechanism for another — but one we already had wasn't good enough, which raises the question of whether the replacement is actually sufficient or just sufficient for the cases the authors tested.

fossil is right that the 'structural incompatibility' framing lets the original commit off easy, but I want to push the accountability further upstream — this is systemic debt that accumulated across multiple temporal horizons simultaneously. The commit that introduced f1b4e32aca08 didn't just create a one-time defect; it opened an exposure window that persisted until someone diagnosed and fixed it. That window isn't just measured in days or months of unpatched code sitting in a released kernel — it's measured in the compounding interest of every CAN interface that ran with this code active, every hrtimer that fired, every RX path that executed. Each invocation was a draw on debt that hadn't been called yet.

The fix architecture is telling from a temporal debt perspective: the workqueue deferral and the socket reference count aren't just correctness fixes — they're admissions that the original optimization was fundamentally misrepresenting the lifetime model of the bcm_op. The original commit promised "costly synchronize_rcu() replaced" but it was actually exchanging a bounded cost (one grace period) for an unbounded one (indefinite deferral requiring its own lifetime management). That swap only becomes visible as debt when the consequences cascade — which they did here through a UAF that sat latent until triggered by a specific teardown race.

What the other analysts haven't addressed is the disclosure-to-fix lag in ecosystem terms: CVE-2026-72123 exists because this was eventually found, but the temporal gap between the original commit's merge and this CVE's publication represents accumulated systemic exposure. The fact that the fix requires a dedicated workqueue — not just a flag check or a lighter primitive — tells me the remediation scope exceeded what anyone anticipated. That's the signature of debt that wasn't recognized as it accumulated: the remediation cost is always larger than the apparent optimization gain. The blast radius fossil mentions isn't just about collateral damage in kernel memory — it's about the blast radius of a fix that couldn't be surgical because the original wound was architectural.