The Linux kernel project has released a fix for a locking bug, tracked as CVE-2025-37884, that enables a local, low-privileged user to deadlock and freeze a host. The flaw resides in the interaction between the BPF tracing subsystem and the kernel’s global event mutex. Without the update, an attacker with limited access can force a system into an unrecoverable hang, creating a denial-of-service vector that requires a hard reboot.

The flaw: a textbook lock-order inversion

At the heart of the problem is a circular wait between two CPUs. On one, a detach or free path (like _free_event() → perf_kprobe_destroy()) acquires the global event_mutex and then calls synchronize_rcu_tasks_trace(), which blocks until all RCU trace readers complete. On another CPU, a BPF load or test path (e.g., bpf_prog_test_run_syscall()) enters an RCU read-side trace critical section with rcu_read_lock_trace() and then attempts to acquire that same event_mutex through trace_set_clr_event(). If these two sequences run concurrently, CPU A waits for RCU readers to finish, while CPU B — itself an RCU reader — waits for the mutex. Neither can proceed.

Multiple code paths were identified that could produce this ordering, making the deadlock practical to hit under real workloads. Kernel maintainers noted that any local actor with the ability to invoke BPF or tracing interfaces — even with minimal capabilities — could trigger the lockup.

The fix: deferring work to a workqueue

The upstream remedy, applied across stable kernel trees, sidesteps the problem by converting the problematic synchronous path into deferred work. Specifically, the call to trace_set_clr_event() is moved from a context that holds RCU read locks into a workqueue callback. That callback runs in process context, where it can safely acquire event_mutex without creating an inversion. By decoupling the lock acquisition from the RCU read-side section, the circular wait is eliminated.

This approach is a conservative, well-understood kernel pattern. It avoids a redesign of BPF or tracing internals, keeps the patch small and backportable, and preserves existing behavior for most consumers. Vendors have already integrated the change into their distribution kernels.

What it means for you

For home and workstation users: The risk is low if you run a single-user system with no untrusted local access. However, if you share a machine or run containers, an attacker with a shell could exploit this bug to hang the entire host. Patching is recommended.

For system administrators and IT teams: This is an availability-critical patch. Any multi-tenant server, developer workstation used for BPF experimentation, or observability infrastructure running an unpatched kernel is vulnerable. A local user with low privileges (or even a compromised process in a container) can bring down the entire machine. In cloud and data center environments, the impact of an unplanned host freeze is severe — think scheduled downtime for reboot, lost work, and potential data corruption. Apply vendor kernel updates immediately.

For developers working with BPF and tracing: The fix is transparent in most cases. The deferred work means attach/detach operations are no longer guaranteed to be complete on return from the call; any code that relied on strictly synchronous completion may need review. However, the kernel community assessed the change as unlikely to cause regressions in typical tracing workflows.

How we got here

BPF has evolved from a simple packet filter into a general-purpose in-kernel execution engine used by networking, security, and observability tools. This growth brought more complex interactions with the tracing and perf subsystems. Locking between RCU and mutexes is notoriously tricky, and several prior BPF-related fixes have addressed similar orderings, race conditions, or verifier bugs. CVE-2025-37884 is the latest in a line of availability issues that underscore how a small ordering mistake can have outsized operational consequences.

The deadlock was uncovered during routine code review or testing (the exact discovery path hasn’t been detailed publicly), and a fix was merged into the mainline kernel. It has since been backported to multiple longterm and stable releases, including 6.1, 6.6, 6.12, and 6.14 lines. Distribution vendors — including Canonical, Debian, Red Hat, SUSE, and Amazon Linux — have published their own advisories and updated packages.

What to do now

1. Patch your kernel
The definitive fix is to install a kernel version that includes the workqueue change. Consult your Linux distribution’s security advisory for the exact package name and version. Many vendors offer live patches for critical systems that cannot be rebooted immediately. If you manage a fleet, prioritize hosts that are multi-tenant, exposed to untrusted users, or used for BPF development.

2. Apply temporary mitigations if patching is delayed
- Disable unprivileged BPF by setting kernel.unprivileged_bpf_disabled=1 (or kernel.unprivileged_bpf=0 on older kernels). This prevents most non-root users from loading BPF programs.
- Restrict capabilities: ensure processes do not hold CAP_BPF, CAP_PERFMON, or CAP_SYS_ADMIN unless strictly necessary. Use tools like systemd unit restrictions or container runtime policies.
- Harden perf event access: review kernel.perf_event_paranoid settings and limit access to perf_event_open().

3. Monitor for suspicious activity
Watch for unexplained system hangs, especially when correlated with BPF or tracing activity. System logs from journald or kernel messages may show lockup warnings before a complete freeze. In container environments, restrict which workloads can invoke bpf() or perf_event_open() syscalls.

4. Validate your update
After patching, run your typical BPF and tracing workloads in a test environment to confirm the deadlock no longer reproduces. Vendor advisory notes typically indicate which kernel builds contain the fix.

Outlook

As BPF continues to underpin critical observability and security tools, its attack surface will remain under scrutiny. This incident highlights that even availability-only bugs can be severe when they provide a low-barrier path to host denial. The kernel community’s response — a surgical, backportable fix — shows good engineering discipline, but operators must stay proactive. Regular kernel patching, capability hygiene, and access controls are the best defense against this class of flaw. Keep an eye on future BPF security advisories and consider automating kernel update policies where feasible.