A pair of kernel maintainers closed a subtle but operationally important deadlock in the Linux kernel’s BPF/tracing stack: a locking inversion between the RCU trace path and the global tracing event mutex could hang a host under realistic local workloads, and the upstream remedy delegates trace_set_clr_event() to a workqueue to break the dependency. This fix, tracked as CVE‑2025‑37884, is an availability‑first patch — it does not expose data confidentiality or integrity directly, but it does create a deterministic way for a local, low‑privileged actor to freeze system activity by provoking a kernel‑level deadlock unless kernels are updated or mitigations applied. (
cvefeed.io)
Background / Overview
The Linux Berkeley Packet Filter (BPF) subsystem has evolved into a general‑purpose in‑kernel execution and instrumentation framework used by networking, observability, policy enforcement, and security tooling. BPF interacts closely with the kernel tracing and perf subsystems to attach programs to tracepoints, kprobes, uprobes and related hooks. That interaction requires careful locking and RCU (Read‑Copy‑Update) coordination so that trace consumers and short‑lived attach/detach operations do not race with each other.
CVE‑2025‑37884 is not a memory corruption or privilege‑escalation bug; it is a classical
lock-order inversion that produces a circular wait between two CPUs. In kernel terms, one CPU can hold the global tracing lock (event_mutex) and then call a blocking RCU synchronization helper (synchronize_rcu_tasks_trace), while a second CPU can be inside an RCU read‑side trace section (rcu_read_lock_trace) and attempt to take the same event_mutex. Those two paths, taken together, produce a deadlock. The kernel fix removes the problematic synchronous lock dependency by delegating one side of the interaction to a workqueue — converting a blocking, in‑context lock acquisition into deferred work so the lock ordering is always respected. (
cvefeed.io)
How the deadlock occurs — a technical walkthrough
To reason about the bug, it helps to follow the two sequences that can interleave on different CPUs:
- CPU A (detach / free path)
- _free_event()
- perf_kprobe_destroy()
- mutex_lock(&event_mutex)
- perf_trace_event_unreg()
- synchronize_rcu_tasks_trace()
- CPU B (BPF load / test path)
- bpf_prog_test_run_syscall()
- rcu_read_lock_trace()
- bpf_prog_run_pin_on_cpu()
- bpf_prog_load()
- bpf_tracing_func_proto()
- trace_set_clr_event()
- mutex_lock(&event_mutex)
The critical observation is that CPU A holds event_mutex and then
blocks waiting for RCU‑trace readers to drain (synchronize_rcu_tasks_trace()). At the same time CPU B is inside an RCU read‑side trace critical section (rcu_read_lock_trace()) and then attempts to acquire event_mutex. If these two paths are concurrent, CPU A waits for any RCU readers to finish, and CPU B — being an RCU reader — waits for event_mutex. Neither can proceed: a textbook circular wait. The kernel maintainers identified multiple code paths that could produce this ordering, making the deadlock practical to reach under certain workloads. (
cvefeed.io)
Why this matters operationally: deadlocks inside the kernel are not contained to a single process. When a CPU is stuck inside a global kernel lock or sync primitive, scheduling and I/O can stall in ways that make the entire host appear hung, requiring a reboot to recover. That is precisely the
availability hazard called out in public advisories and CVE scoring for this issue.
The upstream fix — what changed and why it works
The upstream remedy adopted by kernel maintainers avoids the problematic synchronous dependency by deferring the trace_set_clr_event() path to a workqueue. In practice, that means:
- Instead of directly calling trace_set_clr_event() while holding RCU read‑side context (and thus creating the potential for locking inversion), the code schedules a small unit of work to run asynchronously in process context (workqueue).
- The workqueue callback then takes event_mutex and performs the trace attachment/detachment in a context that does not hold RCU read locks that could be waited on by synchronize_rcu_tasks_trace().
- By moving the event_mutex acquisition to a deferred context, the lock ordering is preserved: callers that will later call synchronize_rcu_tasks_trace() are not actively waiting for RCU readers that are simultaneously trying to take event_mutex.
This is a common and conservative kernel pattern: when two subsystems have incompatible locking expectations, perform the operation asynchronously by scheduling work in a well‑defined context where locks may be acquired safely. The practical effect is to preserve correctness without large redesign of BPF or perf internals. The change has been applied in stable kernel trees and is reflected in vendor advisories and stable backports. (
cvefeed.io)
Who’s affected and where patches landed
CVE databases and vendor trackers collectively list a broad set of affected kernel versions and distributions. The vulnerability and patch appeared in upstream Linux trees and were included in multiple stable backports; vendors have mapped and packaged those backports into their kernel updates:
- Canonical (Ubuntu) issued advisories and security updates for affected kernels (multiple USN advisories). Users of Ubuntu kernels should apply the listed linux-image upgrades to reach patched kernels.
- Debian and Debian LTS tracked the issue and its stable fixes; the Debian security tracker lists CVE‑2025‑37884 and points to the relevant fixes.
- Red Hat, SUSE, Oracle Linux and Amazon Linux all mapped the same upstream change into their own advisories or security repositories; Amazon Linux 2023 listed explicit package updates and kernel livepatch entries for affected builds.
- The NVD and other aggregators record a CVSS v3.1 base score of 5.5 (Medium) reflecting a local‑attack, availability‑impact profile. The databases also classify the bug under CWE‑667: Improper Locking.
Practical note: vendors’ published fixed versions vary by kernel line (6.1, 6.2, 6.6, 6.12, 6.14, etc.) and some stable branches received backports at different times. Administrators must consult their distribution’s security advisory to pick the exact package or backport recommended for the deployed kernel flavor and update accordingly. Aggregators such as OSV and NVD provide maps and links to vendor advisories for quick triage.
Impact and exploitability — what attackers can (and cannot) do
This vulnerability is primarily an
availability denial‑of‑service (DoS) vector, not a code‑execution or data exfiltration flaw. Key operational characteristics:
- Attack vector: Local. An attacker needs the ability to trigger the BPF/tracing code paths in question (for example by loading/tracing BPF programs or invoking bpf_prog_test_run). The attack is not remote in the sense of being exploitable over the network without local code execution or privileged access.
- Privileges required: Low — many of the tracing and BPF interfaces can be reached by users with limited capabilities on kernels configured to allow unprivileged BPF, or by processes holding modern, fine‑grained capabilities (e.g., CAP_BPF / CAP_PERFMON in newer kernels). The advisories note the attack complexity is low when required interfaces are available. (cvefeed.io)
- Consequence: High availability impact — the deadlock can produce a host hang that typically requires a reboot to recover. There is no direct confidentiality or integrity impact recorded. (cvefeed.io)
- Exploitation in the wild: As of public advisories and database entries, there is no widely circulated proof‑of‑concept demonstrating remote or mass exploitation. EPSS/attack metrics for this CVE stayed low, reflecting the local nature and the fact that most enterprise systems either restrict unprivileged BPF or run vendor kernels that shipped the fix. Nonetheless, because the consequence is host denial, the issue is treated as operationally important by cloud and data‑center operators.
Recommended mitigations and operational steps
If you operate Linux hosts — especially multi‑tenant servers, developer workstations used to test BPF/tracing, or observability infrastructure — take the following prioritized actions:
- Apply vendor patches as the primary fix.
- Update to the patched kernel versions or install vendor backports and livepatches where offered. Vendor advisories from Ubuntu, Debian, SUSE, Amazon Linux and others list the exact package names and fixed versions. This is the only comprehensive remedy; schedule kernel upgrades or livepatch application per your maintenance policies.
- If immediate patching is impractical, apply temporary hardening:
- Disable unprivileged BPF syscalls by setting kernel.unprivileged_bpf_disabled (or kernel.unprivileged_bpf on older kernels) to restrict bpf() to privileged processes. Many distributions and STIGs recommend this as a mitigation when untrusted users exist. This reduces the attack surface for tracing/BPF‑driven DoS.
- Restrict capabilities: ensure processes do not hold unnecessary kernel capabilities such as CAP_BPF, CAP_PERFMON or CAP_SYS_ADMIN. Capability hygiene reduces the number of actors that can exercise the vulnerable code paths.
- Harden perf access: if your environment relies on perf_event interfaces, review kernel.perf_event_paranoid and capability treatment. The perf capability model has evolved (CAP_PERFMON was introduced to provide finer granularity), and some distributions patched behavior inconsistently; assess how your kernel honors CAP_PERFMON and adjust controls accordingly.
- Operational containment:
- Limit who can load BPF or perf tools: configure SELinux/AppArmor, systemd unit restrictions, or container runtime policies so that only trusted administrators and job types may attach BPF programs or use perf_event_open.
- In container environments, apply runtime restrictions to avoid letting untrusted containers load BPF programs against the host kernel.
- Monitor for repeated failures or systemwide hang symptoms — sudden kernel hangs correlated with BPF/tracing activity likely indicate hitting the lock inversion; logs from systemd, journald, and perf tooling may surface hints prior to a complete hang.
- Testing and validation:
- After applying patches or mitigations, validate your test cases: exercise common tracing and BPF workflows in a controlled environment to confirm the deadlock no longer reproduces. Vendors often publish CVE notes indicating which kernel builds include the fix; use these as the target for validation. (cvefeed.io)
Why the fix is the right tradeoff — and where caution remains
The maintainers chose a conservative fix (defer work onto a workqueue) rather than a broad redesign of tracing/BPF locking semantics. That is an appropriate engineering trade: it eliminates the circular wait with minimal behavioral impact and little surface for regressions.
Strengths of the approach:
- Minimal API change: user‑visible behavior for most tracing consumers is preserved.
- Low regression risk: deferring to a workqueue is a well‑understood kernel mechanism that limits the change surface.
- Backportable: the patch is small and suitable for stable tree backports, enabling quicker vendor fixes. (cvefeed.io)
Remaining caveats and potential risks:
- Deferred work implies asynchronous semantics — callers that previously expected synchronous attach/detach completion must account for eventual completion if their code depended on immediate effect. Kernel developers usually chose this carefully to avoid visible breakage, but complex consumer code may need review.
- The presence of multiple BPF/tracing fixes in the same release window reminds operators that BPF is an active and fast‑moving kernel area. Hardening BPF attack surface (sysctl controls, capability restrictions) remains an ongoing maintenance burden.
Broader context: BPF locking is a recurring operational surface
CVE‑2025‑37884 is one in a series of relatively small but operationally important BPF/tracing fixes that have appeared over recent kernel releases: race conditions, verifier corner‑cases and locking mismatches are recurring themes because BPF touches many subsystems. Previous and contemporaneous fixes in the tracing and perf stacks (for example, perf/sec related deadlocks and BPF timer fixes) illustrate that even small misorders between RCU contexts and mutex acquisitions can produce host‑level outages. Operationally, this reinforces the need for rigorous vendor patching and capability hardening in production fleets.
Practical checklist for sysadmins (quick reference)
- Inventory: Identify hosts running kernels in versions flagged as affected (consult vendor advisories and NVD/OSV records for exact ranges). (cvefeed.io)
- Patch: Apply vendor kernel updates or livepatches as provided by your distribution. Prioritize multi‑tenant and observability hosts.
- Temporary hardening: If patching is delayed, disable unprivileged BPF and tighten perf permissions (kernel.unprivileged_bpf_disabled and capability review).
- Monitor: Watch for unexplained hard hangs, scheduling stalls, or perf/tracing errors in logs. Schedule tests that exercise tracing attachments post‑patch.
- Policy: Restrict which users and containers may load BPF programs and attach perf/tracing hooks; require administrative review for changes to those policies.
Final assessment
CVE‑2025‑37884 is a textbook kernel availability bug: not exotic, but practically consequential. The upstream fix is small, well‑scoped and backportable; multiple vendors have already incorporated the change into stable updates and published advisories. For administrators, the path forward is straightforward but time‑sensitive: prioritize kernel updates for exposed hosts, harden unprivileged BPF access where possible, and treat tracing/BPF interfaces as an attack surface that requires capability hygiene and operational controls.
The kernel community’s prompt and surgical approach here — delegating the problematic operation to a deferred workqueue — demonstrates good engineering discipline: solve the lock‑ordering without destabilizing the broader BPF/tracing contract. That said, the recurrence of BPF/tracing issues across kernel releases underlines a broader operational reality: as BPF becomes central to observability and control, operators must balance the need for rich in‑kernel tooling against the risk of kernel‑level availability faults. Remaining prudent about who can load BPF code, keeping kernels up to date, and applying vendor advisories promptly will materially reduce exposure to this class of DoS issues. (
cvefeed.io)
Source: MSRC
Security Update Guide - Microsoft Security Response Center