CVE-2024-41045

What it actually does

Use-after-free condition in the Linux kernel BPF timer subsystem when bpf_timer_cancel_and_free is invoked concurrently with timer callbacks or map element freeing, allowing the hrtimer structure to be freed while still enqueued on the timer wheel.

Why it matters to the business

Kernel crashes, denial of service, or potential privilege escalation on systems running untrusted or attacker-controlled BPF programs; requires kernel updates on affected Linux distributions and may disrupt services until patched.

How an attack unfolds

An attacker loads a BPF program containing timers, triggers concurrent map updates or cancellations that race with timer callbacks, forces the RCU grace period to expire before the timer fires, and reuses the freed hrtimer memory to achieve arbitrary kernel code execution or a crash.

How to fix it

Update the Linux kernel to a version containing commit 7aa5a19279c3639ae8b758b63f05d0c616a39fa1 or later; rebuild and reboot all affected systems; disable untrusted BPF program loading until updated where feasible.

How to confirm the fix worked

Verify the running kernel contains commit 7aa5a19279c3639ae8b758b63f05d0c616a39fa1 via git log or kernel version string; test BPF timer workloads for absence of deadlocks and UAF reports under concurrent cancellation; confirm with kernel selftests for bpf_timer.

Typical attack path

1. Load malicious or crafted BPF program with timers into the kernel
2. Trigger concurrent bpf_map_update_elem operations and timer callbacks
3. Force RCU grace period expiration while timer remains enqueued
4. Reuse freed hrtimer memory for code execution or denial of service

How to detect it

Review kernel logs for oops/panic messages referencing bpf_hrtimer, bpf_timer_cancel_and_free, or hrtimer UAF; inspect audit logs for unusual BPF program loads or map updates by non-root processes; correlate with workload crashes during BPF map operations.

What your security team should do

• Prioritize kernel updates on all systems exposing BPF to untrusted users
• Restrict CAP_BPF and unprivileged BPF loading via sysctl until patched
• Monitor for kernel oops or panic logs involving bpf_hrtimer
• Apply the fix in downstream distributions and validate with regression tests