CVE-2021-47486

What it actually does

NULL pointer dereference in RISC-V BPF JIT error path when jit_data->header is NULL after failure to converge in NR_JIT_ITERATIONS, causing kernel panic on call to bpf_jit_binary_free().

Why it matters to the business

Unexpected system crashes on RISC-V Linux systems that compile and load untrusted or complex BPF programs, leading to loss of availability for workloads relying on eBPF.

How an attack unfolds

An attacker crafts a BPF program whose JIT compilation fails to converge within the iteration limit; the kernel then passes a NULL header to the free function and crashes before any mitigation can occur.

How to fix it

Apply the upstream fix that adds a NULL check before calling bpf_jit_binary_free() in the RISC-V BPF JIT; update to a kernel containing commit resolving CVE-2021-47486.

How to confirm the fix worked

Verify the presence of the NULL-check guard in arch/riscv/net/bpf_jit_core.c; confirm no crash occurs when loading BPF programs that previously triggered the iteration-limit path.

Typical attack path

1. Attacker obtains ability to load BPF programs (unprivileged or via a service that accepts them)
2. Submit a specially constructed BPF bytecode that forces the RISC-V JIT into repeated relocation attempts
3. JIT iteration limit is reached and header remains NULL
4. Kernel dereferences the NULL pointer inside bpf_jit_binary_free() and panics

How to detect it

Inspect kernel logs (dmesg, /var/log/kern.log) for oops or panic messages referencing bpf_jit_binary_free and riscv; correlate with process creation of BPF loaders around the same timestamp.

What your security team should do

• Prioritize kernel updates on all RISC-V production systems that accept untrusted BPF programs
• Restrict unprivileged BPF loading via sysctl kernel.unprivileged_bpf_disabled until patched
• Monitor for kernel oops/panic logs containing bpf_jit_binary_free on RISC-V hardware