CVE-2026-68198

The patch replacing timer_delete() with timer_delete_sync() is mechanically trivial, but the vulnerability exposes something more concerning than a single use-after-free: a recurring pattern of timer API misuse that likely exists elsewhere in the kernel, and a re-arm race via mod_timer() that is more architecturally dangerous than the CVSS 8.8 suggests. The core issue isn't simply that the callback hadn't finished executing when the timer was deleted. The callback can re-arm itself via mod_timer() while aggr_reset_state() is running — meaning even if you audited every caller of this function, you'd still have a window where a self-rearming timer races against structure teardown. This transforms the bug from a straightforward UAF into something harder to reason about: a callback that extends its own lifetime during destruction, suggesting it was never designed for async destruction in the first place. This raises the uncomfortable question: how many other timer-using structures in the kernel assume synchronous teardown they don't actually guarantee? The kernel timer API structurally rewards the unsafe choice — timer_delete() is non-blocking, which makes it feel cleaner in async code, while timer_delete_sync() blocks and violates intuitions about proper callback design. The timer API has been substantially reformed (timer_setup() replaced init_timer() to force callback unbinding), but code written during the 2010-2014 unstable period — when the safe patterns were still being negotiated — often predates these reforms entirely and has never been touched by subsequent modernization passes. The ath6kl driver supports AR6001/AR6002 chipsets, Qualcomm's early 802.11n hardware that hasn't been mainstream for a decade. This is low-exercised code where the bug could have been latent for years. The EPSS score of 0.00268 reflects that: low asset value, low exploitation probability. But the pattern — non-synchronous timer deletion before kfree — is the same smell found in CVE-2015-7833, CVE-2016-9750, CVE-2019-7221, and others. Each was treated as a one-off. The gap between CVSS 8.8 and EPSS 0.00268 tells you this isn't being actively exploited — but it doesn't tell you whether the pattern exists in higher-stakes code with similar structural failures. You should treat this CVE as a forcing function: audit your codebase for timer_delete() calls in destruction paths, particularly in drivers or subsystems that haven't been touched since the timer_setup() migration. The fix here is trivial. The question is whether that fix is an isolated incident or a symptom of legacy code that's been flying under the maintenance radar — a shadow codebase where dangerous idioms persist precisely because no one is watching.

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