CVE-2021-47317

What it actually does

In the powerpc64 eBPF JIT the validation for atomic instructions examined the wrong instruction field instead of the immediate value, causing programs containing non-BPF_ADD atomics (such as BPF_FETCH) to be accepted and incorrectly compiled.

Why it matters to the business

Systems running affected kernels on powerpc64 hardware may experience soft lockups or crashes when eBPF programs that use modern atomic operations are loaded, disrupting workloads that rely on BPF.

How an attack unfolds

An attacker supplies a crafted eBPF program that encodes an atomic operation other than plain add in the immediate field; the faulty JIT check passes the program, emits incorrect machine code, and execution of that code produces a soft lockup.

How to fix it

Upgrade the Linux kernel to a version containing commit 91c960b0056672 (or the equivalent backport) that inspects the correct immediate field in the powerpc64 JIT; for the listed jumpserver package apply commit d0321a74f1713d031560341c8fd0a1859e6510d8.

How to confirm the fix worked

Confirm the kernel source contains the corrected check that reads the immediate field before accepting atomic operations; re-run the atomic bounds test from the BPF selftests to verify lockup no longer occurs.

Typical attack path

1. Craft eBPF program containing BPF_ATOMIC with non-BPF_ADD immediate value
2. Load the program via bpf() syscall on powerpc64
3. JIT compiler incorrectly accepts and translates the program
4. Execution of the resulting code triggers soft lockup

How to detect it

Look in kernel logs for soft lockup messages immediately after eBPF program loads; examine audit logs for bpf() syscalls that load programs containing atomic operations on powerpc64.

What your security team should do

• Apply the kernel patch or distribution update that fixes the powerpc64 JIT immediate-field check
• Restrict unprivileged BPF loading until the fix is deployed
• Monitor for soft lockups on powerpc64 systems after loading eBPF programs