CVE-2024-53160 - Data Race in Linux Kernel RCU/kfree Handling

A nasty race condition in how the Linux kernel manages delayed freeing of memory could, in some edge cases, cause memory corruption or system crashes. Specifically, this was found in the RCU (Read-Copy-Update) subsystem’s kvfree_call_rcu() and kfree_rcu_monitor() functions interacting with timers. This bug, CVE-2024-53160, has now been fixed by moving some timer-related code under a spinlock, so only one CPU can mess with the timer at a time.

What is CVE-2024-53160?

*CVE-2024-53160* is a concurrency bug (aka data race) reported by Kernel Concurrency Sanitizer (KCSAN) in the Linux kernel 6.12-rc2. It affects the way delayed freeing (“kvfree”) of RCU-managed memory interacts with kernel timers. Two kernel threads could simultaneously read and write the same expiration timer field without protection, risking memory corruption.

If a malicious process could trigger or exploit weird timings here, they might destabilize the kernel or crash the system. There is no PoC (proof-of-concept) remote exploit, but the bug could potentially be leveraged in some privilege escalation or DoS tricks if unpatched.

Anatomy of the Bug

When RCU needs to free memory dynamically sized above PAGE_SIZE, it uses kvfree_call_rcu() instead of the usual kfree_call_rcu(). In a nutshell, the function schedules a delayed work item using a timer. However, different kernel threads could access and modify the timer's expire field (timer.expires) at the same time without locking.

Here’s the problematic flow

1. Thread A schedules or reschedules the monitor work (calls kvfree_call_rcu()), holding krcp->lock.
2. Thread B (a worker thread running in kfree_rcu_monitor()) sees that more work may be needed and wants to re-arm the timer – *but* it does not take the same krcp->lock.

KCSAN reports both threads can thus race on the same memory, reading/writing 8 bytes concurrently, which is a classic data race.

Below is a section of output from KCSAN when this bug is hit

BUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu

read to xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1:
 schedule_delayed_monitor_work kernel/rcu/tree.c:352 [inline]
 kvfree_call_rcu+x3b8/x510 kernel/rcu/tree.c:3839
 ... <snip> ...

write to xffff888237d1cce8 of 8 bytes by task 56 on cpu :
 __mod_timer+x578/x7f kernel/time/timer.c:1173
 add_timer_global+x51/x70 kernel/time/timer.c:133
 ... <snip> ...

Here you see two different tasks simultaneously reading/writing to the same memory address!

Here’s a simplified example of the scheduling function from kernel/rcu/tree.c

static void schedule_delayed_monitor_work(struct krcp_struct *krcp, unsigned long delay)
{
    // ... do stuff ...
    // This is where the problematic access happens
    mod_timer(&krcp->monitor_work.timer, jiffies + delay);
    // ... do more stuff ...
}

And this function might be called without always holding a lock to protect krcp->monitor_work.timer.

The Fix

What changed?
The Linux kernel fix now ensures that both kvfree_call_rcu() and kfree_rcu_monitor() always take the same spinlock (krcp->lock) before modifying the timer, removing the race. If you want to see the code fix on the mailing list:

* Kernel patch discussion - lore.kernel.org

Fixed code snippet

// Add locking to avoid races:
spin_lock(&krcp->lock);
mod_timer(&krcp->monitor_work.timer, jiffies + delay);
spin_unlock(&krcp->lock);

Now, only one thread can touch the timer at a time. Problem solved!

It happens in RCU memory freeing paths, not usually directly controlled from userspace.

- But: Local attackers can sometimes force heavy bpf() map updates (which use RCU freeing), and trigger the function under stress.

A brute-force attacker could try to fill up the kernel with objects, rapidly free/update them using BPF or similar APIs, and hope the race occurs often enough to cause a crash—or, in theory, corrupt kernel memory for escalation.

Simple "DoS" Trigger Pseudocode

// Requires BPF permissions and a debug kernel
for (;;) {
    bpf_update_map_value(my_map, key, valueA);
    bpf_update_map_value(my_map, key, valueB);
    // Do this fast in multiple threads to stress RCU
}

But this is unreliable for privilege escalation without additional kernel bugs. In most real-world scenarios, this bug will “just” panic (crash) the kernel with a KCSAN or slab error if triggered.

Kernel 6.12 and earlier: Vulnerable if unpatched.

- Any modern Linux running custom BPF maps, aggressive RCU usage, or exposing untrusted BPF commands *should upgrade*.

Check your distro releases:

- Red Hat advisory
- Ubuntu tracker
- Debian tracker

If you build your own kernel, cherry-pick the fix from upstream mainline.

Resources & References

- Patch discussion and technical details
- CVE-2024-53160 NIST entry
- RCU internals, kernel docs
- KCSAN kernel docs

Summary

*CVE-2024-53160* is a kernel bug that allowed concurrency races in timer handling for delayed RCU memory freeing. While not easily exploited from user space, it can potentially crash the kernel or create security risks. Patch your kernel if you’re affected!

*This content is original and exclusive, written in simple language for fast understanding. Feel free to share or use it in your own security updates – just link back!*

Timeline

Published on: 12/24/2024 12:15:24 UTC
Last modified on: 05/04/2025 09:54:33 UTC