CVE-2024-49861

What it actually does

The flaw permits BPF helpers annotated with ARG_PTR_TO_{LONG,INT} to perform writes into read-only BPF maps (such as .rodata) because check_func_arg never sets meta->raw_mode and check_helper_mem_access defaults to BPF_READ when the base register is PTR_TO_MAP_VALUE, allowing the subsequent check_map_access_type call to succeed on frozen maps.

Why it matters to the business

Systems relying on read-only BPF maps for integrity of configuration or constant data may experience unauthorized modification of kernel-visible state, increasing risk of tampering in environments that use eBPF for security or observability.

How an attack unfolds

An attacker authors a BPF program that passes pointers to read-only map values as arguments to helpers expecting ARG_PTR_TO_LONG or ARG_PTR_TO_INT; the verifier incorrectly treats the access as read-only and permits loading; at runtime the helper performs a direct write through the pointer, altering the frozen map contents.

How to fix it

Upgrade the Linux kernel to a version containing commit 988e55abcf7fdb8fc9a76a7cf3f4e939a4d4fb3a. Rebuild and reload any affected BPF programs after the update. No action is required for actionpack.

How to confirm the fix worked

Confirm the running kernel contains commit 988e55abcf7fdb8fc9a76a7cf3f4e939a4d4fb3a; attempt to load a test BPF program that writes through an ARG_PTR_TO_LONG argument to a frozen map and verify the verifier now rejects it.

Typical attack path

1. Compile and load a BPF program that invokes helpers with ARG_PTR_TO_{LONG,INT} arguments pointing into a frozen map
2. Verifier path in check_func_arg skips raw_mode and check_helper_mem_access assumes BPF_READ
3. Program attaches and executes the helper write
4. Read-only map contents are mutated, bypassing intended immutability

How to detect it

Inspect kernel logs for BPF verifier warnings or map access type checks during program loads; look for unexpected runtime writes to maps marked read-only via tracing of helper functions.

What your security team should do

• Prioritize kernel updates on all systems that compile or run untrusted BPF programs
• Review existing BPF code for use of helpers that write through fixed-size pointer arguments
• Enable BPF verifier logging during program load in test environments to surface similar issues