CVE-2024-42239: Vulnerability in Linux Linux

Severity: highType: vulnerabilityCVE-2024-42239

In the Linux kernel, the following vulnerability has been resolved: bpf: Fail bpf_timer_cancel when callback is being cancelled Given a schedule: timer1 cb timer2 cb bpf_timer_cancel(timer2); bpf_timer_cancel(timer1); Both bpf_timer_cancel calls would wait for the other callback to finish executing, introducing a lockup. Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps track of all in-flight cancellation requests for a given BPF timer. Whenever cancelling a BPF timer, we must check if we have outstanding cancellation requests, and if so, we must fail the operation with an error (-EDEADLK) since cancellation is synchronous and waits for the callback to finish executing. This implies that we can enter a deadlock situation involving two or more timer callbacks executing in parallel and attempting to cancel one another. Note that we avoid incrementing the cancelling counter for the target timer (the one being cancelled) if bpf_timer_cancel is not invoked from a callback, to avoid spurious errors. The whole point of detecting cur->cancelling and returning -EDEADLK is to not enter a busy wait loop (which may or may not lead to a lockup). This does not apply in case the caller is in a non-callback context, the other side can continue to cancel as it sees fit without running into errors. Background on prior attempts: Earlier versions of this patch used a bool 'cancelling' bit and used the following pattern under timer->lock to publish cancellation status. lock(t->lock); t->cancelling = true; mb(); if (cur->cancelling) return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false; The store outside the critical section could overwrite a parallel requests t->cancelling assignment to true, to ensure the parallely executing callback observes its cancellation status. It would be necessary to clear this cancelling bit once hrtimer_cancel is done, but lack of serialization introduced races. Another option was explored where bpf_timer_start would clear the bit when (re)starting the timer under timer->lock. This would ensure serialized access to the cancelling bit, but may allow it to be cleared before in-flight hrtimer_cancel has finished executing, such that lockups can occur again. Thus, we choose an atomic counter to keep track of all outstanding cancellation requests and use it to prevent lockups in case callbacks attempt to cancel each other while executing in parallel.

AI Analysis

Technical Summary

CVE-2024-42239 is a vulnerability identified in the Linux kernel's BPF (Berkeley Packet Filter) subsystem, specifically related to the handling of BPF timers and their cancellation mechanism. The issue arises when multiple BPF timer callbacks attempt to cancel each other simultaneously, leading to a potential deadlock. The vulnerability occurs because the bpf_timer_cancel function waits synchronously for the callback to finish executing. If two callbacks each call bpf_timer_cancel on the other's timer, both calls wait indefinitely for the other to complete, causing a lockup. The root cause is the lack of proper tracking of concurrent cancellation requests, which leads to a circular wait condition. The fix introduces an atomic counter named 'cancelling' in the bpf_hrtimer structure to track all in-flight cancellation requests. When a cancellation is attempted, the function checks if there are outstanding cancellations and returns an error (-EDEADLK) if so, preventing the deadlock. This approach replaces earlier attempts that used a boolean flag, which suffered from race conditions and improper serialization. The patch ensures that cancellation requests from callbacks are serialized and that non-callback contexts can cancel timers without error. This vulnerability affects Linux kernel versions identified by the commit hash b00628b1c7d595ae5b544e059c27b1f5828314b4 and was published on August 7, 2024. No known exploits are reported in the wild at this time.

Potential Impact

For European organizations, this vulnerability could lead to denial of service (DoS) conditions on systems running vulnerable Linux kernels with BPF timer usage. Since BPF is widely used for networking, observability, and security monitoring, a deadlock in timer cancellation could cause critical kernel threads to hang, potentially freezing parts of the system or degrading performance. This could impact servers, network appliances, and cloud infrastructure relying on Linux, especially those using advanced BPF programs for traffic filtering or telemetry. While the vulnerability does not directly allow privilege escalation or data leakage, the resulting system lockups could disrupt business operations, cause downtime, or complicate incident response. Organizations running custom or third-party BPF programs that manipulate timers are at higher risk. The lack of known exploits suggests limited immediate threat, but the complexity of the issue means that sophisticated attackers or misconfigured software could inadvertently trigger the deadlock, affecting system availability.

Mitigation Recommendations

European organizations should prioritize updating their Linux kernels to versions that include the patch for CVE-2024-42239. Kernel updates should be tested in staging environments to ensure compatibility with existing BPF programs. Additionally, organizations should audit their use of BPF timers in custom or third-party software to identify any patterns of mutual cancellation that could trigger deadlocks. Developers should avoid designing BPF timer callbacks that cancel each other simultaneously. Monitoring kernel logs for -EDEADLK errors related to bpf_timer_cancel can help detect attempts to trigger this condition. For critical infrastructure, implementing kernel live patching solutions can reduce downtime when applying fixes. Network and security teams should also review BPF program configurations to minimize complex interdependencies between timers. Finally, organizations should maintain robust incident response plans to quickly recover from potential DoS caused by this vulnerability.