CVE-2024-47702 Linux eBPF Verifier Sign-Extension Vulnerability – Impact, Detection & Mitigation

Introduction

CVE-2024-47702 represents a critical vulnerability in the Linux kernel’s eBPF (Extended Berkeley Packet Filter) subsystem that affects system stability and availability. This security advisory provides Linux administrators, security teams, and DevOps professionals with comprehensive technical analysis, detection strategies, and remediation guidance. Understanding this vulnerability is essential for organizations running modern Linux distributions, particularly those leveraging eBPF for networking, observability, and security monitoring.

What Is CVE-2024-47702?

The Core Vulnerability

CVE-2024-47702 is a verification bypass flaw in the Linux kernel’s eBPF subsystem that allows malicious or incorrectly compiled eBPF programs to pass validation checks they should fail. The vulnerability specifically involves improper handling of 32-bit sign-extended loads targeting packet metadata fields within the __sk_buff context structure.

When an eBPF program attempts to load packet pointer fields (data, data_end, or data_meta) using a sign-extended 32-bit operation, the verifier fails to detect and reject this unsafe instruction. This oversight allows the program to load and execute, where it subsequently corrupts critical kernel memory addresses at runtime.

Why the eBPF Verifier Matters

The eBPF verifier is a critical security component in the Linux kernel. It performs static analysis on all eBPF bytecode before execution to ensure:

• Memory safety: Programs cannot access arbitrary kernel memory
• Control flow validity: Jump targets and branches remain within program bounds
• Register state tracking: Values remain consistent throughout execution
• Context field access: Only legitimate kernel data structures are accessible

The verifier acts as a gatekeeper, preventing untrusted or buggy eBPF code from destabilizing the kernel. A bypass in this verification layer directly undermines kernel security and stability.

Impact on System Stability

When a sign-extended packet pointer load executes at runtime, the 32-bit sign-extension operation corrupts the high-order bits of the 64-bit kernel virtual address. This corruption renders the address invalid, leading to:

• Kernel page faults when dereferencing the corrupted pointer
• Immediate kernel panic or crash
• System unavailability until reboot
• Loss of running services and data in flight

The impact is purely a Denial of Service (DoS) condition—the vulnerability does not enable code execution or privilege escalation, but it effectively crashes the system.

Affected Systems and Versions

Linux Kernel Versions at Risk

CVE-2024-47702 affects Linux kernel versions that include commit 1f1e864b6555 (“bpf: Handle sign-extension ctx member accesses”) prior to the official patch release.

Affected kernel series:

• Linux 5.10 and later (where eBPF sign-extension support was introduced)
• All stable and long-term support (LTS) kernels from 5.10 onward until patched

Specific vulnerable versions include:

• 5.10.x through 5.10.z (before patch)
• 5.15.x through 5.15.z (before patch)
• 5.19.x through 5.19.z (before patch)
• 6.0.x through 6.x.z (before patch)

Subsystem Scope: eBPF Verifier

The vulnerability is confined to the eBPF subsystem (kernel/bpf/ directory), specifically:

• Affected component: verifier.c – the is_valid_access() callback
• Affected context type: __sk_buff (socket buffer context)
• Affected fields: data, data_end, data_meta

Other eBPF context types (e.g., bpf_sock, bpf_sock_ops) are not affected by this specific flaw.

Configuration Dependencies

The severity of this vulnerability depends on kernel configuration:

Technical Deep Dive

How Sign-Extension Corrupts Packet Pointers

To understand the vulnerability, consider how packet pointers are represented in the kernel:

Normal 64-bit packet data address (example):

0xFFFF888000000000  (kernel virtual address)

After 32-bit sign-extension (corrupted):

0xFFFFFFFF00000000  (sign-extended from lower 32 bits)

The sign-extension operation takes the lower 32 bits of the address and extends the sign bit across the upper 32 bits. For kernel addresses in the 0xFFFF8880... range, this operation produces an invalid address that does not correspond to valid kernel memory.

The Verifier’s Failure Point

The eBPF verifier’s is_valid_access() function is responsible for validating all memory accesses within an eBPF program. Prior to the patch, this function did not explicitly check whether a sign-extension operation was being applied to packet pointer fields.

Vulnerable code path:

eBPF program load (sys_bpf)
    ↓
bpf_prog_load()
    ↓
bpf_check() [verifier entry point]
    ↓
is_valid_access() [FAILS TO REJECT sign-extended load]
    ↓
convert_ctx_accesses() [transforms context accesses]
    ↓
Program passes verification ✓ [INCORRECT]
    ↓
Program is attached to kernel hook
    ↓
Packet arrives → eBPF program executes
    ↓
Sign-extended load corrupts r2 register
    ↓
Dereference of corrupted pointer → KERNEL PANIC ✗

Runtime Execution and Kernel Crash Mechanism

When the eBPF program executes at runtime, the sign-extension instruction operates on the register holding the packet data address:

r2 = *(u64 *)(r1 + 208)  /* Load 64-bit packet data address from __sk_buff */
r2 = (s32)r2            /* Sign-extend 32-bit value into 64-bit register */
r3 = *(u64 *)(r1 + 80)   /* Load data_end */
r0 = r2
r0 += 8
if r3 > r0 goto pc+1

After the sign-extension, r2 contains an invalid address. Any subsequent operation using r2 as a memory address (load, store, or arithmetic) triggers a page fault in kernel space, which cannot be handled gracefully and results in a kernel panic.

Code Example: Vulnerable Cast Pattern

The vulnerability is triggered by specific C code patterns that compilers translate into sign-extended loads:

/* Vulnerable pattern: explicit cast to int then back to pointer */
void *data = (void *)(long)(int)skb->data;
/* Vulnerable pattern: implicit narrowing cast */
int data_offset = (int)skb->data;
void *ptr = (void *)(long)data_offset;
/* Vulnerable pattern: conditional sign-extension */
if (skb->data_meta) {
    int meta = (int)skb->data_meta;  /* Sign-extension here */
    // ... use meta
}

These patterns are uncommon in production code but can appear in:

• Buggy eBPF program source code
• Compiler-generated code under certain optimization levels
• Fuzzing-generated test cases
• Intentionally malicious eBPF programs

Attack Vectors and Threat Scenarios

Local Denial of Service Attack

Attack scenario:

1. Attacker gains local access to a system with unprivileged eBPF enabled (kernel.unprivileged_bpf_disabled = 0)
2. Attacker crafts a malicious eBPF program containing a sign-extended 32-bit load on __sk_buff->data
3. Attacker loads the program via the bpf() syscall with BPF_PROG_LOAD command
4. Program passes verification due to the verifier bypass
5. Attacker attaches the program to a network hook (e.g., BPF_PROG_TYPE_SOCKET_FILTER)
6. Attacker sends a packet matching the filter criteria
7. eBPF program executes, sign-extension corrupts the packet pointer
8. Kernel crashes immediately, causing system-wide DoS

Impact:

• All running services become unavailable
• Data in flight is lost
• System requires manual reboot
• Monitoring and alerting systems go offline

Privilege Requirements

Unprivileged attack (if kernel.unprivileged_bpf_disabled = 0):

• No special privileges required
• Any local user can trigger the vulnerability
• Risk level: CRITICAL

Privileged attack (if kernel.unprivileged_bpf_disabled = 1):

• Requires CAP_SYS_ADMIN or CAP_BPF capability
• Typically limited to root or container privileged processes
• Risk level: MEDIUM (insider threat or compromised privileged process)

Exploitation Difficulty and Likelihood

Difficulty: LOW

• Crafting the malicious eBPF program is straightforward
• Public eBPF tools (e.g., bpftool, libbpf) can be used
• No advanced exploitation techniques required

Likelihood: MEDIUM

• Requires local access to the system
• Requires eBPF subsystem to be enabled (default on modern distributions)
• Requires unprivileged eBPF to be enabled (varies by distribution)

Severity Assessment

CVSS Score and Rating

CVSS v3.1 Vector:

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

CVSS v3.1 Score: 5.5 (MEDIUM)

Scoring breakdown:

• Attack Vector (AV:L): Local only—attacker must have local system access
• Attack Complexity (AC:L): Low—no special conditions required
• Privileges Required (PR:L): Low—unprivileged user can exploit (if eBPF enabled)
• User Interaction (UI:N): None—no user interaction required
• Scope (S:U): Unchanged—impact limited to the affected system
• Confidentiality (C:N): None—no data disclosure
• Integrity (I:N): None—no data modification
• Availability (A:H): High—system crash and complete unavailability

Availability Impact

The vulnerability causes complete loss of availability for the affected system:

• Immediate impact: Kernel panic and system crash
• Duration: Until manual reboot (no automatic recovery)
• Scope: All services and users on the system
• Data loss: Potential loss of in-flight data and unsaved state

Scope and Exploitability Factors

Factors increasing severity:

• ✓ Unprivileged eBPF enabled (common on development systems)
• ✓ eBPF programs from untrusted sources (e.g., container images)
• ✓ Network-facing eBPF programs (e.g., XDP, socket filters)

Factors decreasing severity:

• ✓ Unprivileged eBPF disabled (hardened configurations)
• ✓ eBPF programs from trusted sources only
• ✓ Kernel version not yet patched (limited exposure window)

Detection and Monitoring

Kernel Log Indicators

Monitor kernel logs for signs of eBPF-related crashes:

# Real-time monitoring
journalctl -f -u kernel | grep -E "BPF|bpf|oops|panic"
# Historical search
dmesg | grep -A 10 "BPF program"
journalctl -b | grep -E "invalid.*address|page fault.*kernel"

Suspicious log patterns:

[  123.456789] BPF program (type 1) load request from uid 1000
[  123.456790] bpf: verifier passed
[  123.456791] BUG: unable to handle page fault for address: 0xffffffff00000000
[  123.456792] #PF: supervisor read access in kernel mode
[  123.456793] #PF: error_code(0x0000) - not-present page
[  123.456794] PGD 1234567 P4D 1234567 PUD 1234567 PMD 0
[  123.456795] Oops: 0000 [#1] SMP

System Call Auditing Techniques

Enable audit rules to track eBPF program loads:

# Add audit rule for bpf syscall
auditctl -a always,exit -F arch=x86_64 -S bpf -F a0=5 -k bpf_prog_load
# Monitor for BPF_PROG_LOAD (command 5)
ausearch -k bpf_prog_load -ts recent
# Generate report
aureport -k bpf_prog_load --summary

Audit log example:

type=SYSCALL msg=audit(1699564800.123:456): arch=c000003e syscall=321 success=yes 
  exit=5 a0=5 a1=0x7fff12345678 a2=0x1000 a3=0x0 items=0 ppid=1234 pid=5678 
  auid=1000 uid=1000 gid=1000 euid=1000 egid=1000 fsuid=1000 fsgid=1000 
  tty=pts/0 ses=1 comm="bpftool" exe="/usr/sbin/bpftool" key="bpf_prog_load"

eBPF Bytecode Inspection Methods

Inspect loaded eBPF programs for suspicious patterns:

# List all loaded eBPF programs
bpftool prog list
# Dump bytecode of specific program
bpftool prog dump xlated id <PROG_ID>
# Search for sign-extension instructions (w<reg> = (s32)<reg>)
bpftool prog dump xlated id <PROG_ID> | grep -E "w[0-9]+ = \(s32\)"
# Check program verification logs
bpftool prog show id <PROG_ID> verbose

Suspicious bytecode pattern:

   0: (79) r2 = *(u64 *)(r1 +208)    ; Load packet data address
   1: (bc) w2 = w2                    ; Sign-extend to 32-bit (SUSPICIOUS)
   2: (79) r3 = *(u64 *)(r1 +80)     ; Load data_end
   3: (0f) r0 += r2                   ; Arithmetic on corrupted pointer

Mitigation and Remediation

Kernel Patch Application

Step 1: Identify your kernel version

uname -r

Step 2: Check if your distribution has released a patched kernel

Step 3: Update the kernel

# Ubuntu/Debian
sudo apt update
sudo apt install linux-image-generic linux-headers-generic
sudo reboot
# RHEL/CentOS/Fedora
sudo dnf update kernel
sudo reboot
# Arch Linux
sudo pacman -Syu linux
sudo reboot

Step 4: Verify the patch is applied

# Check kernel version
uname -r
# Verify eBPF verifier has the fix
grep -r "is_valid_access" /boot/config-$(uname -r) 2>/dev/null || \
  echo "Check kernel source for patch commit"

Disabling Unprivileged eBPF

As an interim mitigation (before patching), disable unprivileged eBPF:

# Temporary (until reboot)
sudo sysctl -w kernel.unprivileged_bpf_disabled=1
# Permanent configuration
echo "kernel.unprivileged_bpf_disabled = 1" | \
  sudo tee -a /etc/sysctl.d/99-disable-unprivileged-bpf.conf
# Apply immediately
sudo sysctl -p /etc/sysctl.d/99-disable-unprivileged-bpf.conf

Verify the setting:

sysctl kernel.unprivileged_bpf_disabled
# Output: kernel.unprivileged_bpf_disabled = 1

Impact of disabling unprivileged eBPF:

• ✓ Prevents unprivileged users from loading eBPF programs
• ✓ Reduces attack surface significantly
• ✗ May break legitimate unprivileged eBPF tools (e.g., bcc tools, bpftrace)
• ✗ Requires root privileges for all eBPF operations

Verification Steps

Verify the patch is applied:

# Method 1: Check kernel version
uname -r | grep -E "5\.(10|15|19)|6\.[0-9]"
# Method 2: Check for the fix commit
git log --oneline | grep -i "sign-extension\|CVE-2024-47702"
# Method 3: Test with a safe eBPF program
bpftool prog list  # Should work normally
# Method 4: Attempt to load a malicious program (in test environment only)
# This should FAIL with "invalid access to packet data"

Verify unprivileged eBPF is disabled:

cat /proc/sys/kernel/unprivileged_bpf_disabled
# Output: 1 (disabled) or 0 (enabled)
# Test as unprivileged user
sudo -u nobody bpftool prog list
# Should fail with "Permission denied" if disabled

Frequently Asked Questions

Root Cause Explanation

Q: What causes CVE-2024-47702?

A: The eBPF verifier incorrectly allowed sign-extended 32-bit loads on packet pointer fields (data, data_end, data_meta). At runtime, sign-extending these 32-bit values corrupts 64-bit kernel virtual addresses, leading to invalid memory access and kernel panic.

The root cause stems from commit 1f1e864b6555, which added support for sign-extended context member accesses but failed to account for the special case of packet pointer fields. These fields contain 64-bit kernel virtual addresses that cannot be safely narrowed to 32 bits and then sign-extended back to 64 bits without corruption.

Code Execution Risk

Q: Can this vulnerability lead to arbitrary code execution?

A: No. Current findings and analysis (including syzbot crash reports) indicate that the sign-extension invalidates the kernel address space pointer, causing runtime failures and kernel panics (Denial of Service) rather than enabling direct code execution.

The corrupted address does not point to executable code or data that an attacker can control. The kernel simply crashes when attempting to dereference the invalid pointer. While a kernel crash is a severe availability impact, it does not provide a pathway to code execution or privilege escalation.

Fix Mechanism

Q: How does the patch fix this issue?

A: The patch updates the is_valid_access() callback in the eBPF subsystem to detect and reject sign-extension requests on packet pointer context loads before program execution. Specifically:

1. Detection: The verifier now checks if a sign-extension operation is being applied to __sk_buff->data, __sk_buff->data_end, or __sk_buff->data_meta
2. Rejection: If detected, the verifier fails the program load with an error message
3. Prevention: Malicious or buggy programs cannot pass verification and therefore cannot execute

The fix is minimal and surgical—it only affects the specific vulnerable code path without impacting legitimate eBPF functionality.

Q: Who can exploit this vulnerability?

A: Local authenticated users or unprivileged users (if unprivileged eBPF is enabled on the system) can load malicious eBPF programs to trigger the flaw. The vulnerability requires:

• Local system access
• Ability to invoke the bpf() syscall with BPF_PROG_LOAD command
• Knowledge of eBPF bytecode or access to tools that generate it

On hardened systems with kernel.unprivileged_bpf_disabled = 1, only root or processes with CAP_SYS_ADMIN capability can exploit the vulnerability.

Q: What is the primary impact of this vulnerability?

A: The primary impact is availability—the vulnerability causes kernel crashes and system instability when triggered, resulting in local Denial of Service. All running services become unavailable until the system is manually rebooted.

There is no impact on confidentiality (data disclosure) or integrity (data modification). The vulnerability does not enable code execution or privilege escalation.

Q: How can I disable unprivileged eBPF?

A: Run the following command to disable unprivileged eBPF immediately:

sysctl -w kernel.unprivileged_bpf_disabled=1

To make this change permanent across reboots, add the following line to /etc/sysctl.conf or create a new file in /etc/sysctl.d/:

echo "kernel.unprivileged_bpf_disabled = 1" | \
  sudo tee /etc/sysctl.d/99-disable-unprivileged-bpf.conf
sudo sysctl -p /etc/sysctl.d/99-disable-unprivileged-bpf.conf

Verify the setting with:

sysctl kernel.unprivileged_bpf_disabled

Conclusion

CVE-2024-47702 is a moderate-severity vulnerability affecting the Linux kernel’s eBPF subsystem. While it does not enable code execution, it provides a straightforward path to local Denial of Service for unprivileged users on systems with unprivileged eBPF enabled.

Recommended actions:

1. Immediate: Disable unprivileged eBPF on production systems (kernel.unprivileged_bpf_disabled = 1)
2. Short-term: Apply kernel patches from your distribution
3. Ongoing: Monitor kernel logs for eBPF-related crashes and audit eBPF program loads

Organizations should prioritize patching systems with unprivileged eBPF enabled, particularly those running untrusted container workloads or multi-tenant environments.

References

1. Linux Kernel BPF Mailing List Discussion:
   https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/

2. Original Commit (Vulnerable):
   1f1e864b6555 – “bpf: Handle sign-extension ctx member accesses”

3. Linux Kernel eBPF Documentation:
   https://www.kernel.org/doc/html/latest/userspace-api/ebpf/index.html

4. CVSS v3.1 Specification:
   https://www.first.org/cvss/v3.1/specification-document

5. eBPF Verifier Source Code:
   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/bpf/verifier.c

Document Version: 1.0
Last Updated: 2024
Classification: Public