Linux kernel bpf: BPF_REFCOUNT field was not marked unique in the verifier's field checks

UnscoredCVE-2026-100074Kernel, userspace & hypervisorcurated

Impact

The verifier's record of special BTF fields did not mark BPF_REFCOUNT as unique, so a BPF type could declare more than one refcount field where the verifier's later reasoning assumes exactly one. On a GPU node the BPF machinery is what observability agents, CNI dataplanes and security agents load, and a verifier bookkeeping gap is a soundness question about that boundary. The upstream record is a one-line oversight fix with no exploit, no score and no described attack scenario, so treat the practical exposure as unestablished rather than as a demonstrated escalation. It is local-only in any case: loading a BPF program with a refcounted kptr field requires privilege, not tenant access.

Who can reach it

Local, and only for a caller that can load BPF programs - CAP_BPF plus CAP_SYS_ADMIN (or unprivileged BPF explicitly enabled). A tenant confined to a GPU pod without BPF capabilities cannot reach the path.

What to do

Pick up the fix from your distribution's stable kernel (three stable commits linked); it ships as a normal kernel update, so each node has to be drained and rebooted. In the meantime, keep BPF program loading restricted to the agents that need it - kernel.unprivileged_bpf_disabled and not granting CAP_BPF to workload pods.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-100074 https://git.kernel.org/stable/c/61e655391cb19c31f94ecd4354f624c81ce4cf75 https://git.kernel.org/stable/c/e42cede6f90177f4f92f80d3de18f628e61d2087

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.