CVE-2024-41045: Linux kernel · bpf: Defer work in bpf_timer_cancel_and_free
Source GCVE Database
Not known to be exploited · CVSS 7.8 High.
Data as of 26 Oct 2026, 13:47 UTC
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 20% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 29 Jul 2024
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
AI-suggested
A fix has been implemented in the Linux kernel to defer timer cancellation work to a global workqueue, preventing deadlocks and use-after-free conditions. Users should apply the official kernel patch or update to a kernel version that includes this fix. Since this is not a cloud service, remediation depends on applying the vendor's patch. Patch status is confirmed by the vendor advisory describing the fix.
Description
In the Linux kernel, the following vulnerability has been resolved: bpf: Defer work in bpf_timer_cancel_and_free Currently, the same case as previous patch (two timer callbacks trying to cancel each other) can be invoked through bpf_map_update_elem as well, or more precisely, freeing map elements containing timers. Since this relies on hrtimer_cancel as well, it is prone to the same deadlock situation as the previous patch. It would be sufficient to use hrtimer_try_to_cancel to fix this problem, as the timer cannot be enqueued after async_cancel_and_free. Once async_cancel_and_free has been done, the timer must be reinitialized before it can be armed again. The callback running in parallel trying to arm the timer will fail, and freeing bpf_hrtimer without waiting is sufficient (given kfree_rcu), and bpf_timer_cb will return HRTIMER_NORESTART, preventing the timer from being rearmed again. However, there exists a UAF scenario where the callback arms the timer before entering this function, such that if cancellation fails (due to timer callback invoking this routine, or the target timer callback running concurrently). In such a case, if the timer expiration is significantly far in the future, the RCU grace period expiration happening before it will free the bpf_hrtimer state and along with it the struct hrtimer, that is enqueued. Hence, it is clear cancellation needs to occur after async_cancel_and_free, and yet it cannot be done inline due to deadlock issues. We thus modify bpf_timer_cancel_and_free to defer work to the global workqueue, adding a work_struct alongside rcu_head (both used at _different_ points of time, so can share space). Update existing code comments to reflect the new state of affairs.
References
- nvd.nist.gov/vuln/detail/CVE-2024-41045 (opens in a new tab)
- git.kernel.org/stable/c/5eaa11c500ed07f505f86cec07d5593a71927e26 (opens in a new tab)
- git.kernel.org/stable/c/7aa5a19279c3639ae8b758b63f05d0c616a39fa1 (opens in a new tab)
- git.kernel.org/stable/c/a6fcd19d7eac1335eb76bc16b6a66b7f574d1d69 (opens in a new tab)