Look up another CVE · open CVE-2025-21825 in the interactive tracker
CVE-2025-21825
bpf: Cancel the running bpf_timer through kworker for PREEMPT_RT
Published 2025-03-06 (19 months ago) by the Linux kernel CNA. Subsystem kernel/bpf. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2025-21825 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.12.13-1 | Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.12.13-1 | Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.12.13-1 | Update the kernel and reboot. Fixed in 6.12.13-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
kernel/bpf/helpers.c
- What this is
- BPF [GENERAL] (Safe Dynamic Programs and Tools)MAINTAINERS section matched on kernel/bpf/ · bpf@vger.kernel.org · Supported
Check it on the machine
grep -wE 'CONFIG_BPF|CONFIG_BPF_SYSCALL' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switches
- CONFIG_BPF, CONFIG_BPF_SYSCALL
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2025-03-06 (19 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- kernel/bpf
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.15 | 6.12.13 | 33e47d957307 |
| 5.15 | 6.13.2 | fbeda3d939ca |
| 5.15 | 6.14 | 58f038e6d209 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The vulnerable path is entered through the bpf() syscall (BPF_MAP_UPDATE_ELEM / BPF_MAP_DELETE_ELEM on a preallocated hash map, or a BPF program performing the update), which requires local access to the system. There is no remote or adjacent-network trigger.
- AC:LAttack complexity, low
- The attacker controls both sides of the race: it arms the bpf_timer, authors the callback (which can be made to run for milliseconds via bpf_loop, keeping softirq_expiry_lock held and hrtimer_try_to_cancel() returning -1 the whole time), and hammers map_update_elem from another CPU, making the hit near-deterministic — as the upstream selftest demonstrates.
- PR:LPrivileges required, low
- The bpf_timer helpers and map creation are gated on bpf_token_capable(CAP_BPF), which resolves to bpf_ns_capable() and is therefore delegable into an unprivileged user namespace via a BPF token, and the overwrite itself only needs write access to the map fd (e.g. a bpffs-pinned map). This is consistent with the CNA's PR:L treatment of other BPF-subsystem CVEs.
- UI:NUser interaction, none
- The attacker performs every step itself — creating the map, arming the timer, and issuing the overwriting update. No action by any other user or administrator is needed.
- S:UScope, unchanged
- The corruption and the lockup are confined to kernel memory and the kernel's own scheduling state, within the same security authority. No VM, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- Sleeping mid-bpf_obj_free_fields() breaks the non-preemptible window that protects htab->extra_elems, letting another task on the same CPU re-install the element while its special fields are still being torn down — yielding a use-after-free on kptr-referenced kernel objects that can be leveraged for arbitrary kernel memory disclosure.
- I:HIntegrity impact, high
- The same reuse window causes bpf_obj_free_fields() to xchg-and-drop kptrs and cancel timers belonging to a live map element, producing refcount underflow and double-free of refcounted kernel objects — a classic heap-corruption write primitive usable for control-flow hijack.
- A:HAvailability impact, high
- The immediate symptom is a "BUG: scheduling while atomic" splat (a panic under panic_on_warn), and the task deschedules while holding the bucket raw spinlock with hardirqs disabled, so other CPUs spin on it indefinitely — leading to hard lockup, deadlock against the timer softirq thread, or panic from the resulting UAF.