BPF verifier fixes plug refcount_acquire holes for borrowed kptrs

Two bugs in the BPF verifier’s handling of bpf_refcount_acquire for borrowed RCU kernel pointers could let a program with only CAP_BPF crash the kernel or take a reference through a recycled address.

Ning Ding posted fixes on the BPF list. In the first case, the verifier treated an RCU-loaded borrowed map kptr as an owning reference and therefore treated bpf_refcount_acquire’s return value as non-NULL. At runtime another thread can still drop the last owning reference first, so the helper returns NULL. Passing that unchecked NULL into bpf_obj_drop can take down the kernel.

In the second, after bpf_rcu_read_unlock the pointer is marked untrusted, yet the verifier still accepted it as a refcount_acquire argument. Once the original object is dropped, that address can be reused for another refcounted object. Ding’s CAP_BPF-only reproducer saw a successful acquire on such a stale pointer.

Both paths get regression tests. Reviewer Kumar Kartikeya Dwivedi asked for a tighter model rather than a one-off check: treat untrusted allocated object pointers as invalid for helpers and kfuncs in general, while still allowing safe probe-style reads. Ding is revising the series along those lines. Stable backports were also flagged as needed because the broken commits are already in released kernels.

The flaws matter because CAP_BPF is enough to reach them. Closing the holes keeps borrowed RCU kptrs from being mistaken for live owning references after the protection window ends.