CVE-2024-41045 Linux Kernel eBPF Timer Race Condition & Use‑After‑Free – Risks, Detection, and Patch

Executive Summary

CVE-2024-41045 is a critical vulnerability in the Linux kernel’s extended Berkeley Packet Filter (eBPF) subsystem that affects the bpf_timer_cancel_and_free routine. This flaw allows concurrent operations involving eBPF timer callbacks to trigger either a kernel deadlock or a Use-After-Free (UAF) memory condition.

An attacker with local capabilities to execute eBPF programs can exploit this vulnerability to cause a system-wide Denial of Service (DoS) through kernel deadlock or potentially achieve local privilege escalation via memory corruption. The Linux kernel community resolved this issue by deferring timer cancellation tasks to the global workqueue using a work_struct structure that shares memory space with rcu_head.

CVSS v3.1 Score: 7.8 (High)
CVSS Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

What Is CVE-2024-41045?

Vulnerability Overview

CVE-2024-41045 is a race condition vulnerability residing in the Linux kernel’s eBPF subsystem, specifically within the bpf_timer_cancel_and_free function located in kernel/bpf/helpers.c. The vulnerability emerges from improper synchronization when multiple threads attempt to cancel and free eBPF timer structures concurrently.

eBPF (extended Berkeley Packet Filter) is a powerful in-kernel virtual machine that allows unprivileged users to run sandboxed programs in the Linux kernel. eBPF timers enable these programs to schedule delayed callbacks. However, the mechanism for safely canceling these timers under concurrent access patterns was fundamentally flawed.

The vulnerability manifests in two distinct exploitation paths:

1. Kernel Deadlock Path: Synchronous timer cancellation operations block indefinitely when concurrent callbacks attempt to cancel each other.
2. Use-After-Free Path: Asynchronous cancellation attempts leave enqueued timers referencing freed memory structures.

Why This Matters for Your Infrastructure

If your Linux systems run eBPF-based security tools, monitoring solutions, or container runtimes (Docker, Kubernetes, etc.), they likely utilize eBPF timers. This vulnerability poses several critical risks:

• Availability Impact: Affected systems can experience sudden kernel panics or complete system hangs, disrupting service availability.
• Security Tool Failure: eBPF-based security monitoring and enforcement mechanisms may fail catastrophically.
• Privilege Escalation: Memory corruption from the UAF condition could enable attackers to escalate privileges from unprivileged to root.
• Container Escape: Container security policies enforced via eBPF may be bypassed through exploitation.

Organizations running production Linux systems—particularly those using Kubernetes, cloud-native infrastructure, or advanced networking solutions—should prioritize assessment and patching of this vulnerability.

Technical Breakdown: How the Vulnerability Works

The Deadlock Problem

The original implementation of bpf_timer_cancel_and_free relied on synchronous hrtimer_cancel() calls to safely terminate high-resolution timers. This function blocks the caller until the timer callback completes execution.

The deadlock scenario:

Thread A (Timer Callback 1)          Thread B (Timer Callback 2)
    |                                    |
    +---> Calls bpf_map_update_elem     +---> Calls bpf_map_update_elem
    |     (updates shared map)           |     (updates shared map)
    |                                    |
    +---> Triggers bpf_timer_cancel_and_free
    |     Calls hrtimer_cancel()         |
    |     (BLOCKS waiting for CB2)       |
    |                                    +---> Triggers bpf_timer_cancel_and_free
    |                                    |     Calls hrtimer_cancel()
    |                                    |     (BLOCKS waiting for CB1)
    |                                    |
    X (DEADLOCK - circular wait)         X

When two timer callbacks attempt to cancel each other’s timers, both threads enter hrtimer_cancel() and block indefinitely, waiting for the other callback to complete. This creates a circular wait condition—a classic deadlock scenario.

The kernel detects this as a hung task and eventually triggers a kernel panic, rendering the system unavailable.

The Use-After-Free Problem

Developers attempted to fix the deadlock by switching from hrtimer_cancel() to the non-blocking hrtimer_try_to_cancel() function. However, this introduced a memory safety vulnerability.

The UAF exploitation sequence:

1. Timer callback arms a timer with a far-future expiration time
   bpf_hrtimer structure: [hrtimer | rcu_head | callback_data]
   Status: ENQUEUED in hrtimer subsystem
2. Concurrent thread calls bpf_timer_cancel_and_free()
   Calls hrtimer_try_to_cancel() → FAILS (timer still enqueued)
   Proceeds to kfree_rcu(bpf_hrtimer, rcu_head)
3. RCU grace period expires
   Memory containing bpf_hrtimer is freed
   But hrtimer subsystem still has reference to struct hrtimer
4. Far-future timer expires
   Kernel attempts to execute callback
   References freed memory → USE-AFTER-FREE
   Potential kernel crash or memory corruption

The root cause: hrtimer_try_to_cancel() can fail if the timer is actively executing or about to execute. When it fails, the code proceeds to free the memory via RCU, but the timer remains enqueued in the hrtimer subsystem. When the timer eventually fires, it accesses freed memory.

Why Previous Fixes Failed

The vulnerability represents a fundamental design flaw that couldn’t be solved with simple synchronization primitives:

• Blocking cancellation (hrtimer_cancel) causes deadlocks under concurrent access
• Non-blocking cancellation (hrtimer_try_to_cancel) creates UAF conditions
• Spin-waiting would cause performance degradation and still risk deadlock
• Mutex protection would serialize all timer operations, defeating the purpose of concurrent timers

The solution required architectural change: deferring the cancellation work to a separate execution context (the global workqueue) where deadlock cannot occur and where memory can be safely freed after the timer is guaranteed to have stopped executing.

Who Is at Risk?

Affected Linux Kernel Versions

CVE-2024-41045 affects Linux kernel versions that introduced eBPF timer support through the current release cycle, specifically:

• Affected Range: Linux 5.16 through 6.10 (and potentially earlier stable branches)
• Fixed In: Kernel versions incorporating the commit "bpf: Defer work in bpf_timer_cancel_and_free" (July/August 2024 stable releases)

Specific affected versions include:

• Linux 5.16, 5.17, 5.18, 5.19
• Linux 6.0, 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 6.9, 6.10 (pre-patch)

Check your kernel version:

uname -r

Required Attacker Capabilities

Exploitation requires local access to the target system. The attacker must be able to:

1. Load eBPF programs containing BPF timer operations
2. Create BPF maps with timer elements
3. Trigger concurrent timer operations to induce the race condition

Privilege Requirements:

• Systems with unprivileged eBPF enabled (default on many distributions):

• Any local user can exploit this vulnerability

• No special privileges required

• Systems with unprivileged eBPF disabled (kernel.unprivileged_bpf_disabled = 1):

• Attacker requires CAP_BPF or CAP_SYS_ADMIN capability

• Typically limited to root or privileged containers

Systems with Unprivileged eBPF Enabled

Most modern Linux distributions ship with unprivileged eBPF enabled by default, making this vulnerability exploitable by any local user. Systems at highest risk include:

• Development workstations with multiple users
• Shared hosting environments with unprivileged tenants
• Container platforms allowing user-defined eBPF programs
• Kubernetes clusters with eBPF-based CNI plugins or security policies
• Cloud VMs with standard Linux distributions

Verify your system’s eBPF configuration:

cat /proc/sys/kernel/unprivileged_bpf_disabled
# Output: 0 = unprivileged eBPF enabled (vulnerable)
# Output: 1 = unprivileged eBPF disabled (reduced risk)
# Output: 2 = unprivileged eBPF disabled, CAP_BPF required

Real-World Attack Scenarios

Scenario A: Kernel Deadlock & System Crash

Attacker Profile: Unprivileged local user on a shared system

Attack Flow:

1. Attacker writes a malicious eBPF program utilizing BPF timers:

// Simplified eBPF program structure
SEC("tracepoint/syscalls/sys_enter_openat")
int timer_callback(void *ctx) {
    struct bpf_map_elem *elem = bpf_map_lookup_elem(&timer_map, &key);
    if (elem) {
        bpf_timer_start(&elem->timer, 1000000, 0);  // Arm timer
        bpf_map_update_elem(&timer_map, &key, &new_elem, 0);  // Trigger cancel
    }
    return 0;
}

1. Attacker loads the program and creates a BPF map with timer elements
2. Attacker triggers the tracepoint repeatedly to create concurrent timer callbacks
3. Two callbacks attempt to cancel each other’s timers simultaneously
4. Both threads enter hrtimer_cancel() and block indefinitely
5. Kernel detects hung task after timeout (typically 120 seconds)
6. System panics with message:

[  120.456789] INFO: task kworker/u8:0:123 blocked for more than 120 seconds.
[  120.456790] Call Trace:
[  120.456791]  schedule+0x...
[  120.456792]  schedule_timeout+0x...
[  120.456793]  wait_for_completion+0x...
[  120.456794]  hrtimer_cancel+0x...
[  120.456795]  bpf_timer_cancel_and_free+0x...

Impact: System becomes unresponsive, services fail, requires manual restart

Scenario B: Memory Corruption & Privilege Escalation

Attacker Profile: Unprivileged local user seeking privilege escalation

Attack Flow:

1. Attacker crafts an eBPF program that:

• Creates a BPF map with timer elements
• Arms timers with far-future expiration times (e.g., 1 hour)
• Concurrently triggers map element deletion

1. Attacker exploits the race condition:

// Thread 1: Timer callback
SEC("tracepoint/syscalls/sys_enter_write")
int arm_timer(void *ctx) {
    struct timer_elem *elem = bpf_map_lookup_elem(&timer_map, &key);
    if (elem) {
        bpf_timer_start(&elem->timer, 3600000000000, 0);  // 1 hour
    }
    return 0;
}
// Thread 2: Delete element (via userspace)
// bpf_map_delete_elem(map_fd, &key);
// This triggers bpf_timer_cancel_and_free()

1. Race condition window:

• hrtimer_try_to_cancel() fails (timer still enqueued)
• kfree_rcu() schedules memory for freeing
• RCU grace period expires, memory is freed
• Timer remains in hrtimer subsystem’s queue

1. When timer fires (after 1 hour or triggered via clock manipulation):

• Kernel accesses freed bpf_hrtimer structure
• Attacker has controlled the freed memory layout
• Memory corruption enables arbitrary kernel code execution

1. Attacker achieves root privilege escalation

Impact: Complete system compromise, attacker gains kernel-level code execution

Severity Assessment

CVSS Score & Metrics

CVSS v3.1 Score: 7.8 (High)

Vector Breakdown:

Impact on Availability, Integrity & Confidentiality

Availability (HIGH):

• Kernel deadlock causes immediate system unavailability
• Kernel panic requires manual intervention and restart
• Services dependent on the system become inaccessible
• Recovery time: 15-30 minutes minimum (including restart and boot)

Integrity (HIGH):

• Use-After-Free enables arbitrary kernel memory writes
• Attacker can modify kernel data structures
• Security policies and access controls can be bypassed
• Kernel code can be patched in-memory for persistent compromise

Confidentiality (HIGH):

• Memory corruption can leak sensitive kernel data
• Attacker can read arbitrary kernel memory
• Cryptographic keys, authentication tokens, and user data may be exposed
• Information disclosure enables further attacks

Exploitability Factors

Factors Increasing Exploitability:

• ✓ Unprivileged eBPF enabled by default on most distributions
• ✓ No special privileges required on default systems
• ✓ Exploit code is relatively straightforward to develop
• ✓ Race condition can be reliably triggered with proper timing
• ✓ Affects multiple kernel versions across several years

Factors Decreasing Exploitability:

• ✗ Requires local system access (not remotely exploitable)
• ✗ Timing-dependent (AC: High) – requires precise concurrent execution
• ✗ May require kernel debugging knowledge for UAF exploitation
• ✗ Some hardening measures (SMACK, SELinux) may limit eBPF loading

How to Detect CVE-2024-41045

Kernel Panic & Log Analysis

Deadlock Detection:

Monitor system logs for hung task warnings and kernel panics:

# Check kernel logs for hung tasks
journalctl -u kernel | grep -i "hung task"
dmesg | grep -i "hung task"
# Look for specific patterns
grep -E "bpf_timer|hrtimer_cancel|use-after-free" /var/log/kern.log

Typical deadlock signature in logs:

[  120.456789] INFO: task kworker/u8:0:123 blocked for more than 120 seconds.
[  120.456790] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  120.456791] kworker/u8:0   D    0   123      2 0x00000000
[  120.456792] Call Trace:
[  120.456793]  __schedule+0x...
[  120.456794]  schedule+0x...
[  120.456795]  schedule_timeout+0x...
[  120.456796]  wait_for_completion+0x...
[  120.456797]  hrtimer_cancel+0x...
[  120.456798]  bpf_timer_cancel_and_free+0x...

KASAN Detection Methods

Kernel Address Sanitizer (KASAN) will detect Use-After-Free conditions:

Enable KASAN in kernel configuration:

CONFIG_KASAN=y
CONFIG_KASAN_GENERIC=y  # or CONFIG_KASAN_SW_TAGS
CONFIG_KASAN_INLINE=y

KASAN UAF detection output:

==================================================================
BUG: KASAN: use-after-free in hrtimer_run_queues+0x...
Read of size 8 at addr ffff88810a1234c0 by task kworker/u8:0/123
CPU: 0 PID: 123 Comm: kworker/u8:0 Not tainted 6.5.0-rc1+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Call Trace:
 dump_stack_lvl+0x...
 print_address_description.constprop.0+0x...
 print_report+0x...
 kasan_report+0x...
 hrtimer_run_queues+0x...
 update_process_times+0x...
 tick_sched_handle+0x...
Freed by task 456:
 kfree_rcu+0x...
 bpf_timer_cancel_and_free+0x...
 bpf_map_delete_elem+0x...
The buggy address belongs to the object at ffff88810a1234c0
 which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes inside of 256-byte region

Lockdep Alerts & Circular Dependencies

Lockdep Detection (requires CONFIG_PROVE_LOCKING=y):

Monitor for circular lock dependency warnings:

# Check for lockdep warnings in kernel logs
dmesg | grep -A 20 "circular locking dependency detected"
journalctl -u kernel | grep -A 20 "circular locking dependency"

Typical lockdep output for this vulnerability:

======================================================
WARNING: possible circular locking dependency detected
6.5.0-rc1+ #1 Not tainted
------------------------------------------------------
kworker/u8:0/123 is trying to acquire lock:
 (&timer->lock){....}-{2:2}, at: hrtimer_cancel+0x...
but task is already holding lock:
 (&map->lock){....}-{2:2}, at: bpf_map_update_elem+0x...
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
 -> #1 (&map->lock){....}-{2:2}:
        lock_acquire+0x...
        _raw_spin_lock_irqsave+0x...
        bpf_timer_cancel_and_free+0x...
        bpf_map_delete_elem+0x...
 -> #0 (&timer->lock){....}-{2:2}:
        lock_acquire+0x...
        _raw_spin_lock_irqsave+0x...
        hrtimer_cancel+0x...
        bpf_timer_cancel_and_free+0x...
stack backtrace:
CPU: 0 PID: 123 Comm: kworker/u8:0 Not tainted 6.5.0-rc1+ #1

Patch Verification Audit

Verify if the patch is applied:

# Check kernel source for the fix
grep -r "work_struct" /lib/modules/$(uname -r)/kernel/bpf/
# Examine the actual bpf_timer_cancel_and_free implementation
objdump -d /boot/vmlinuz-$(uname -r) | grep -A 50 "bpf_timer_cancel_and_free"
# Check if work_struct is used in timer cancellation
strings /boot/vmlinuz-$(uname -r) | grep -i "defer.*work"

Automated patch verification script:

#!/bin/bash
KERNEL_VERSION=$(uname -r)
KERNEL_SOURCE="/usr/src/linux-headers-${KERNEL_VERSION}"
if [ -f "${KERNEL_SOURCE}/kernel/bpf/helpers.c" ]; then
    if grep -q "work_struct.*bpf_timer_cancel_and_free" "${KERNEL_SOURCE}/kernel/bpf/helpers.c"; then
        echo "✓ Patch appears to be applied"
        exit 0
    else
        echo "✗ Patch NOT applied - system is vulnerable"
        exit 1
    fi
else
    echo "? Cannot verify - kernel source not available"
    exit 2
fi

Remediation: Patching & Mitigation

Apply the Kernel Security Patch

Step 1: Identify your Linux distribution and kernel version

uname -r
cat /etc/os-release | grep PRETTY_NAME

Step 2: Update to patched kernel version

For Ubuntu/Debian:

sudo apt update
sudo apt upgrade linux-image-generic
sudo reboot

For RHEL/CentOS/Fedora:

sudo yum update kernel
sudo reboot

For Arch Linux:

sudo pacman -Syu linux
sudo reboot

For Alpine Linux:

sudo apk update
sudo apk upgrade linux-lts
sudo reboot

Step 3: Verify patch installation

# Check kernel version after reboot
uname -r
# Verify the fix is present
grep -i "defer.*work" /proc/version

Disable Unprivileged eBPF (Immediate Workaround)

Immediate mitigation (before patching) – restrict eBPF to privileged users:

# Temporarily disable unprivileged eBPF
sudo sysctl -w kernel.unprivileged_bpf_disabled=1
# Verify the change
cat /proc/sys/kernel/unprivileged_bpf_disabled
# Output should be: 1

Make the change persistent across reboots:

# Create/edit sysctl configuration file
sudo tee /etc/sysctl.d/99-disable-ebpf.conf > /dev/null <<EOF
# Disable unprivileged eBPF to mitigate CVE-2024-41045
kernel.unprivileged_bpf_disabled = 1
EOF
# Apply the configuration
sudo sysctl -p /etc/sysctl.d/99-disable-ebpf.conf
# Verify persistence
sudo sysctl kernel.unprivileged_bpf_disabled

Important Considerations:

• ⚠️ Disabling unprivileged eBPF may break applications that rely on it
• ⚠️ Container runtimes (Docker, Kubernetes) may require CAPBPF or CAPSYS_ADMIN
• ⚠️ Some monitoring and security tools may stop functioning
• ✓ This is a temporary workaround until kernel patching is complete

Check for affected applications:

# List processes with BPF capabilities
getcap -r / 2>/dev/null | grep bpf
# Check for eBPF programs loaded
sudo bpftool prog list
# Check for BPF maps
sudo bpftool map list

Verify Patch Installation

Comprehensive verification checklist:

#!/bin/bash
echo "=== CVE-2024-41045 Patch Verification ==="
echo ""
# 1. Check kernel version
echo "[1] Kernel Version:"
KERNEL_VERSION=$(uname -r)
echo "    Current: $KERNEL_VERSION"
echo ""
# 2. Check if vulnerable kernel version range
echo "[2] Vulnerability Status:"
if [[ $KERNEL_VERSION =~ ^5\.(16|17|18|19) ]] || [[ $KERNEL_VERSION =~ ^6\.[0-9] ]]; then
    echo "    ⚠️  Potentially vulnerable kernel version"
else
    echo "    ✓ Kernel version outside vulnerable range"
fi
echo ""
# 3. Check unprivileged eBPF status
echo "[3] Unprivileged eBPF Status:"
EBPF_STATUS=$(cat /proc/sys/kernel/unprivileged_bpf_disabled 2>/dev/null)
if [ "$EBPF_STATUS" = "0" ]; then
    echo "    ⚠️  Unprivileged eBPF ENABLED (higher risk)"
elif [ "$EBPF_STATUS" = "1" ]; then
    echo "    ✓ Unprivileged eBPF DISABLED (mitigated)"
else
    echo "    ? Unknown status"
fi
echo ""
# 4. Check for loaded eBPF programs
echo "[4] Loaded eBPF Programs:"
if command -v bpftool &> /dev/null; then
    PROG_COUNT=$(sudo bpftool prog list 2>/dev/null | wc -l)
    echo "    Found $PROG_COUNT eBPF programs"
else
    echo "    bpftool not available"
fi
echo ""
# 5. Check kernel logs for signs of exploitation
echo "[5] Recent Kernel Issues:"
if dmesg | grep -q "use-after-free\|hung task\|bpf_timer"; then
    echo "    ⚠️  Potential exploitation signs detected in kernel logs"
    dmesg | grep -E "use-after-free|hung task|bpf_timer" | tail -5
else
    echo "    ✓ No exploitation signs in recent kernel logs"
fi

Implementation Checklist

Pre-Patch Assessment

• [ ] Inventory Systems

• [ ] Identify all Linux systems running kernel versions 5.16-6.10

• [ ] Document kernel versions across infrastructure

• [ ] Identify systems with unprivileged eBPF enabled

• [ ] Application Dependency Analysis

• [ ] List applications using eBPF (Kubernetes CNI, monitoring tools, security tools)

• [ ] Document eBPF-dependent services

• [ ] Identify potential service disruption from patching

• [ ] Backup & Recovery Planning

• [ ] Verify system backups are current

• [ ] Test backup restoration procedures

• [ ] Document rollback procedures for kernel updates

• [ ] Stakeholder Communication

• [ ] Notify operations teams of planned maintenance

• [ ] Schedule maintenance windows with minimal impact

• [ ] Prepare communication for affected users

Deployment Strategy

• [ ] Staging Environment Testing

• [ ] Deploy patched kernel to test systems first

• [ ] Verify eBPF-dependent applications function correctly

• [ ] Test system stability under normal workload

• [ ] Validate monitoring and logging systems

• [ ] Phased Rollout

• [ ] Phase 1: Non-critical development systems

• [ ] Phase 2: Non-critical production systems

• [ ] Phase 3: Critical infrastructure (with maintenance window)

• [ ] Phase 4: Remaining systems

• [ ] Immediate Workaround Deployment (if patching delayed)

• [ ] Deploy kernel.unprivileged_bpf_disabled = 1 via configuration management

• [ ] Verify setting persists across reboots

• [ ] Monitor for application failures

• [ ] Deployment Execution

• [ ] Update kernel packages

• [ ] Schedule reboots during maintenance windows

• [ ] Execute reboots in coordinated manner

• [ ] Monitor system stability post-reboot

Post-Patch Validation

• [ ] Kernel Verification

• [ ] Confirm patched kernel version running: uname -r

• [ ] Verify patch presence in kernel: grep -i "defer.*work" /proc/version

• [ ] Check for kernel errors in logs: dmesg | grep -i error

• [ ] Application Functionality

• [ ] Verify eBPF-dependent services are running

• [ ] Test Kubernetes networking (if using eBPF CNI)

• [ ] Validate security monitoring tools

• [ ] Check container runtime functionality

• [ ] System Stability

• [ ] Monitor system uptime and stability

• [ ] Check for kernel panics: dmesg | grep -i panic

• [ ] Verify no hung tasks: dmesg | grep -i "hung task"

• [ ] Monitor CPU and memory usage

• [ ] Security Verification

• [ ] Confirm unprivileged eBPF status (if applicable)

• [ ] Verify no unauthorized eBPF programs loaded

• [ ] Check security policy enforcement

• [ ] Review audit logs for suspicious activity

• [ ] Documentation & Closure

• [ ] Document patch deployment completion

• [ ] Update system inventory with new kernel versions

• [ ] Record any issues encountered and resolutions

• [ ] Schedule follow-up verification in 30 days

Frequently Asked Questions

Can CVE-2024-41045 be exploited remotely?

No. CVE-2024-41045 is strictly a local vulnerability requiring direct access to the target system. An attacker must be able to execute code locally to load eBPF programs and trigger the race condition. Remote exploitation is not possible through network-based attack vectors.

However, in cloud environments or container platforms, a compromised container or VM could exploit this vulnerability to escape its isolation boundary and compromise the host kernel.

What kernel versions are affected?

Affected versions:

• Linux 5.16 through 6.10 (pre-patch)
• Specifically any kernel with eBPF timer support (introduced in Linux 5.16)

Fixed versions:

• Linux 5.16.x (with patch)
• Linux 5.17.x (with patch)
• Linux 5.18.x (with patch)
• Linux 5.19.x (with patch)
• Linux 6.0.x (with patch)
• Linux 6.1.x (with patch)
• Linux 6.2.x (with patch)
• Linux 6.3.x (with patch)
• Linux 6.4.x (with patch)
• Linux 6.5.x (with patch)
• Linux 6.6.x (with patch)
• Linux 6.7.x (with patch)
• Linux 6.8.x (with patch)
• Linux 6.9.x (with patch)
• Linux 6.10.x (with patch)
• Linux 6.11+ (includes fix)

Check your kernel: uname -r

What is the root cause of the Use-After-Free condition?

The UAF condition stems from a mismatch between the timer’s lifecycle in the hrtimer subsystem and the memory management of the bpf_hrtimer structure:

1. Timer remains enqueued: When hrtimer_try_to_cancel() fails (because the timer is actively executing or about to execute), the timer remains in the hrtimer subsystem’s queue.

2. Memory is freed: The code proceeds to call kfree_rcu(), scheduling the bpf_hrtimer structure for freeing after an RCU grace period.

3. Grace period expires: The RCU grace period completes, and the memory containing bpf_hrtimer is freed back to the allocator.

4. Timer fires: When the enqueued timer eventually fires (after its scheduled expiration time), the hrtimer subsystem attempts to execute the callback using the freed memory structure.

5. Memory corruption: The kernel accesses the freed memory, causing a use-after-free condition that can lead to information disclosure or arbitrary code execution.

How does the kernel patch resolve both deadlock and UAF issues?

The patch