CVE-2026-45886: bpf: Fix bpf_xdp_store_bytes proto for read-only arg
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix bpfxdpstorebytes proto for read-only arg
While making some maps in Cilium read-only from the BPF side, we noticed that the bpfxdpstorebytes proto is incorrect. In particular, the verifier was throwing the following error:
; ret = ctxstorebytes(ctx, l3off + offsetof(struct iphdr, saddr), &nat->address, 4, 0); 635: (79) r1 = (u64 )(r10 -144) ; R1=ctx() R10=fp0 fp-144=ctx() 636: (b4) w2 = 26 ; R2=26 637: (b4) w4 = 4 ; R4=4 638: (b4) w5 = 0 ; R5=0 639: (85) call bpfxdpstorebytes#190 write into map forbidden, valuesize=6 off=0 size=4
nat comes from a BPFFRDONLYPROG map, so R3 is a PTRTOMAPVALUE. The verifier checks the helper's memory access to R3 in checkmemsizereg, as it reaches ARGCONSTSIZE argument. The third argument has expected type ARGPTRTOUNINITMEM, which includes the MEMWRITE flag. The verifier thus checks for a BPFWRITE access on R3. Given R3 points to a read-only map, the check fails.
Conversely, ARGPTRTOUNINITMEM can also lead to the helper reading from uninitialized memory.
This patch simply fixes the expected argument type to match that of bpfskbstorebytes.
Affected Software
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
The CVSS vector requires local access and low privileges, with no user interaction required. It is not rated as remotely exploitable.
What is the assessed security impact?
The issue is rated medium with a CVSS 3.1 score of 5.5. The vector indicates high availability impact and no confidentiality or integrity impact.
How can I identify whether a BPF program is encountering this problem?
Affected programs can be rejected by the BPF verifier when calling bpf_xdp_store_bytes with data sourced from a BPF_F_RDONLY_PROG map. The verifier reports a "write into map forbidden" error because it treats the helper's third argument as writable uninitialized memory.
Are specific affected Linux kernel versions or a temporary mitigation provided?
No affected version ranges, default-configuration status, or workaround are provided in the available data. The referenced stable kernel commits contain the fix.