BPF verifier fix aims to close kernel stack leaks via callbacks

A patch series from Ihor Solodrai would teach the BPF verifier to treat some callback arguments as valid only for that invocation, closing two ways a BPF program could keep a pointer into kernel stack after the helper that owned it had returned.

The more serious case is bpf_user_ringbuf_drain(). The helper hands its callback a dynamic pointer over a sample and releases that sample as soon as the callback returns. The verifier could describe the pointer's type, but not that it dies with the callback frame. A program that saved the pointer, a slice, or a clone in the caller's context could later use it against reused kernel stack. Solodrai wrote that this has allowed arbitrary kernel read and write since Linux 7.3. Nicholas Carlini reported the issue; Alexei Starovoitov suggested the approach.

A second helper, bpf_for_each_map_elem(), has a narrower leak on array and per-CPU array maps. Those callbacks receive the address of a 32-bit key that lives in the helper's own frame. Saving that pointer and loading through it after iteration returns can expose four bytes of reused kernel stack. Loads of that kind are not fault-protected. Hash-map keys and map values are left alone, because their storage outlives the callback.

The fix gives the callback frame an identifier and makes that identifier the parent of the short-lived argument, so slices and clones inherit the same lifetime. When the frame is popped, the verifier invalidates the id and anything derived from it. Joining verifier states from different callback frames has to pair those ids, or a value could be tied to the wrong frame.

The series also folds in cleanups of how map, timer, and related callbacks initialize their registers. Those changes are described as having no functional effect. In this revision Solodrai dropped Fixes tags and the stable mailing-list copy, so the series as posted is aimed at bpf-next rather than an explicit backport.