CVE-2026-98049: bpf: zero extend the result of an arena 32-bit cmpxchg
In the Linux kernel, the following vulnerability has been resolved:
bpf: zero extend the result of an arena 32-bit cmpxchg
bpfconvertctxaccesses() rewrites an atomic on an arena pointer from BPFSTX | BPFATOMIC to BPFSTX | BPFPROBEATOMIC, and it runs before bpfoptsubregzextlo32rndhi32().
That pass emits an explicit zero extension for a 32-bit cmpxchg even when bpfjitneedszext() is false. This is done because on some architectures 32-bit cmpxchg requires explicit zero extension for the dst register. E.g. on x86-64 'lock cmpxchg' does not change the %eax if comparison is successful, while BPF semantics declare that each operation on a 32-bit register zero extends it's upper half.
iscmpxchginsn() matches BPFMODE == BPFATOMIC only, so an arena cmpxchg misses said zero extension adjustment. This patch adjusts iscmpxchginsn() to match BPFPROBEATOMIC alongside BPFATOMIC.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for this issue to occur?
The issue requires a BPF program using a 32-bit compare-and-exchange operation on an arena pointer. The arena access conversion rewrites that operation as BPF_PROBE_ATOMIC, causing it to miss the explicit destination-register zero extension normally applied to 32-bit cmpxchg operations.
Which systems are most likely to be affected by the incorrect behavior?
The impact is architecture-dependent because the explicit zero extension is required only on some architectures. The description specifically identifies x86-64, where a successful lock cmpxchg does not modify the upper half of the destination register as required by BPF 32-bit register semantics.
How can I determine whether a system includes the fix?
Check whether the installed Linux kernel contains either referenced stable commit: 1c1b476d43a8b6c9bc04600369dd8cc39950d98e or 4814ed6406f3493bd554ad046da5f7fc04833571. The correction makes cmpxchg detection cover BPF_PROBE_ATOMIC as well as BPF_ATOMIC.