Linux Kernel
CVE-2024-26737
HIGH
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
AC:H because reliable race condition exploitation requires precise cross-CPU timing beyond attacker control; PR:L reflects minimum BPF access; AV:L confirmed by kernel-local execution context.
Primary rating from Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67).
CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Lifecycle Timeline
6DescriptionCVE.org
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel
The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer.
bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock();
bpf_timer_cancel_and_free(); spin_lock(); t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t);
/* UAF on t */ hrtimer_cancel(&t->timer);
In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet.
In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock.
Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace period.
AnalysisAI
Use-after-free in the Linux kernel BPF timer subsystem allows a local attacker with low privileges to corrupt kernel heap memory through a race condition between bpf_timer_cancel and bpf_timer_cancel_and_free, potentially achieving full privilege escalation. The race occurs when bpf_timer_cancel_and_free nullifies and frees the timer pointer while bpf_timer_cancel still holds a stale reference, leading to hrtimer dereference on freed memory. No public exploit has been identified at time of analysis, and EPSS sits at 0.24% (15th percentile), indicating limited exploitation interest despite the high CVSS 7.8 score; this is not listed in CISA KEV.
Technical ContextAI
The vulnerability exists in the Linux kernel BPF subsystem within kernel/bpf/helpers.c, affecting the bpf_hrtimer internal structure used by BPF programs that leverage the bpf_timer_* helper API. CWE-416 (Use After Free) is the root cause: bpf_timer_cancel reads timer->timer under a spin lock into a local pointer 't', then releases the lock. Concurrently, bpf_timer_cancel_and_free acquires the same lock, sets timer->timer to NULL, releases the lock, calls hrtimer_cancel, and then kfree(t). When bpf_timer_cancel subsequently calls hrtimer_cancel(&t->timer), it dereferences already-freed kernel memory. The fix defers kfree via RCU grace period (kfree_rcu) in bpf_timer_cancel_and_free and wraps bpf_timer_cancel's timer->timer access in rcu_read_lock/unlock, ensuring the object cannot be freed while the read side holds the RCU lock. CPE data confirms affected versions span multiple stable Linux kernel branches and explicitly include 6.8-rc1 through 6.8-rc5.
RemediationAI
Apply the upstream stable-tree patches referenced in the five kernel git commits linked in the NVD references. Linux distribution maintainers (Red Hat, Ubuntu, Debian, SUSE, and others) will backport these fixes into their respective kernel packages - apply vendor-released kernel updates as soon as they become available for your distribution. As an immediate compensating control where patching is not yet possible, set /proc/sys/kernel/unprivileged_bpf_disabled=1 (or the equivalent sysctl kernel.unprivileged_bpf_disabled=1 in /etc/sysctl.conf) to restrict BPF program loading to privileged processes only, directly eliminating the attack surface for unprivileged local users; note this may break unprivileged observability tools relying on eBPF. Systems that do not require BPF at all can consider building with CONFIG_BPF_SYSCALL disabled as a long-term hardening measure, though this impacts a wide range of kernel tracing and networking features.
Same weakness CWE-416 – Use After Free
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today