CVE-2025-21825 in Linux
Summary
by MITRE • 03/06/2025
In the Linux kernel, the following vulnerability has been resolved:
bpf: Cancel the running bpf_timer through kworker for PREEMPT_RT
During the update procedure, when overwrite element in a pre-allocated htab, the freeing of old_element is protected by the bucket lock. The reason why the bucket lock is necessary is that the old_element has already been stashed in htab->extra_elems after alloc_htab_elem() returns. If freeing the old_element after the bucket lock is unlocked, the stashed element may be reused by concurrent update procedure and the freeing of old_element will run concurrently with the reuse of the old_element. However, the invocation of check_and_free_fields() may acquire a spin-lock which violates the lockdep rule because its caller has already held a raw-spin-lock (bucket lock). The following warning will be reported when such race happens:
BUG: scheduling while atomic: test_progs/676/0x00000003 3 locks held by test_progs/676: #0: ffffffff864b0240 (rcu_read_lock_trace){....}-{0:0}, at: bpf_prog_test_run_syscall+0x2c0/0x830
#1: ffff88810e961188 (&htab->lockdep_key){....}-{2:2}, at: htab_map_update_elem+0x306/0x1500
#2: ffff8881f4eac1b8 (&base->softirq_expiry_lock){....}-{2:2}, at: hrtimer_cancel_wait_running+0xe9/0x1b0
Modules linked in: bpf_testmod(O) Preemption disabled at: [<ffffffff817837a3>] htab_map_update_elem+0x293/0x1500
CPU: 0 UID: 0 PID: 676 Comm: test_progs Tainted: G ... 6.12.0+ #11 Tainted: [W]=WARN, [O]=OOT_MODULE
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)... Call Trace: <TASK> dump_stack_lvl+0x57/0x70 dump_stack+0x10/0x20 __schedule_bug+0x120/0x170 __schedule+0x300c/0x4800 schedule_rtlock+0x37/0x60 rtlock_slowlock_locked+0x6d9/0x54c0 rt_spin_lock+0x168/0x230 hrtimer_cancel_wait_running+0xe9/0x1b0 hrtimer_cancel+0x24/0x30 bpf_timer_delete_work+0x1d/0x40 bpf_timer_cancel_and_free+0x5e/0x80 bpf_obj_free_fields+0x262/0x4a0 check_and_free_fields+0x1d0/0x280 htab_map_update_elem+0x7fc/0x1500 bpf_prog_9f90bc20768e0cb9_overwrite_cb+0x3f/0x43 bpf_prog_ea601c4649694dbd_overwrite_timer+0x5d/0x7e bpf_prog_test_run_syscall+0x322/0x830 __sys_bpf+0x135d/0x3ca0 __x64_sys_bpf+0x75/0xb0 x64_sys_call+0x1b5/0xa10 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ... </TASK>
It seems feasible to break the reuse and refill of per-cpu extra_elems into two independent parts: reuse the per-cpu extra_elems with bucket lock being held and refill the old_element as per-cpu extra_elems after the bucket lock is unlocked. However, it will make the concurrent overwrite procedures on the same CPU return unexpected -E2BIG error when the map is full.
Therefore, the patch fixes the lock problem by breaking the cancelling of bpf_timer into two steps for PREEMPT_RT: 1) use hrtimer_try_to_cancel() and check its return value 2) if the timer is running, use hrtimer_cancel() through a kworker to cancel it again Considering that the current implementation of hrtimer_cancel() will try to acquire a being held softirq_expiry_lock when the current timer is running, these steps above are reasonable. However, it also has downside. When the timer is running, the cancelling of the timer is delayed when releasing the last map uref. The delay is also fixable (e.g., break the cancelling of bpf timer into two parts: one part in locked scope, another one in unlocked scope), it can be revised later if necessary.
It is a bit hard to decide the right fix tag. One reason is that the problem depends on PREEMPT_RT which is enabled in v6.12. Considering the softirq_expiry_lock lock exists since v5.4 and bpf_timer is introduced in v5.15, the bpf_timer commit is used in the fixes tag and an extra depends-on tag is added to state the dependency on PREEMPT_RT.
Depends-on: v6.12+ with PREEMPT_RT enabled
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 02/16/2026
The vulnerability described in CVE-2025-21825 affects the Linux kernel's eBPF subsystem, specifically within the hash table (htab) implementation and how it manages bpf_timer objects under PREEMPT_RT configurations. This issue manifests as a potential deadlock or scheduling violation that occurs during concurrent map updates when elements are overwritten in a pre-allocated hash table. The root cause stems from improper handling of timer cancellation during the update procedure, where the locking hierarchy violates kernel lockdep rules, leading to scheduling while atomic errors.
The technical flaw arises from the interaction between the bucket lock and the bpf timer cancellation mechanism. When an htab element is updated and replaced, the old element must be freed, but this process occurs after the bucket lock is released. However, the freeing operation may attempt to acquire a spin-lock through check_and_free_fields(), which conflicts with the existing raw-spin-lock held by the bucket lock. This conflict is particularly problematic in PREEMPT_RT environments where strict locking requirements apply, as evidenced by the warning message indicating scheduling while atomic error during hrtimer_cancel_wait_running invocation.
This vulnerability directly relates to CWE-661, which describes insufficient control flow management, and aligns with ATT&CK techniques involving privilege escalation and system compromise through kernel-level vulnerabilities. The issue is particularly severe because it affects the core kernel functionality that underpins eBPF program execution, which is widely used for network filtering, tracing, and security monitoring. The problem specifically impacts systems running with PREEMPT_RT enabled, which is common in real-time and embedded systems where deterministic scheduling is required.
The patch implements a two-step approach to resolve the timer cancellation issue under PREEMPT_RT by using hrtimer_try_to_cancel() first to determine if the timer is running, and if so, deferring the actual cancellation through a kworker using hrtimer_cancel(). This approach breaks the problematic lock acquisition sequence while maintaining functional correctness. The fix addresses the fundamental race condition between element reuse and timer cancellation, though it introduces a minor delay in timer cancellation during map reference release. The solution is targeted specifically at PREEMPT_RT configurations, as indicated by the depends-on tag referencing v6.12 with PREEMPT_RT enabled, making it a specialized fix for real-time kernel deployments rather than a general kernel vulnerability.