BPF verifier patch scopes callback args after kernel memory leaks

Ihor Solodrai has posted a six-part series for bpf-next that teaches the BPF verifier to treat some callback arguments as valid only for the life of the callback frame, closing two cases where a program could keep using a pointer after the helper returned.

The sharper flaw sits in bpf_user_ringbuf_drain(). That helper builds a dynptr on its own stack, hands it to the callback, then releases the sample as soon as the callback returns. Because the verifier only typed the register, a program could park the dynptr (or a slice or clone derived from it) in longer-lived context and later touch reused kernel stack, yielding an arbitrary kernel read and write. The weaker case is bpf_for_each_map_elem() over array and percpu-array maps: the key pointer is a u32 on the helper's stack, so storing it and loading after iteration leaks four bytes of kernel stack. Hash-map keys and map values are unaffected; they live in map memory.

Both issues were reported by Nicholas Carlini. Solodrai's approach adds a frame-owned reference kind that is installed when the callback entry is set up and dropped when the frame is popped, invalidating the argument and everything derived from it through the existing reference walk. Diagnostics now say the owning callback returned rather than claiming a resource release the program never performed. Selftests cover the escape routes for the ringbuf dynptr and the array-map key.

On the list, Alexei Starovoitov questioned the new reference type. He noted that spilling a pointer into a caller's frame is already rejected for ordinary stack pointers, and that the ringbuf dynptr only became spillable in 7.3, so simply refusing the spill might fix the bug without the extra machinery. Kumar Kartikeya Dwivedi agreed that the simpler path looks preferable. The series remains under review.