BPF dmabuf iterator can restart and hand programs a kernel pointer

Kang Chen has posted a fix for the kernel's open-coded DMA-buf BPF iterator after finding that a call past the end of the list can start the walk over and return a kernel pointer the verifier treats as zero.

The iterator used a null pointer both for "not started" and for "finished." Once the walk exhausted the list, another next call was read as a fresh start and resumed from the head. Open-coded iterators are supposed to stay drained: after next returns null once, later calls must keep returning null. The verifier records that state and treats those later results as the constant zero. A restarted walk therefore gives the BPF program a live kernel pointer while the verifier believes the register is null.

Chen's first patch parked a finished iterator on an invalid pointer so the state, which is one pointer wide and part of the generated BPF ABI, did not have to grow. Reviewers preferred the opposite convention, already used by the kmem_cache iterator: an invalid pointer means "not started," and null means drained. Alexei Starovoitov asked for that respin, and for a selftest T.J. Mercier wrote that drains an iterator and calls next once more. Existing coverage uses the for-each helper, which stops at the first null and never exercises a drained iterator. Chen's second version follows that shape and carries Mercier's test. Christian König acked the test.

The same null collision is not unique to DMA-buf. Mercier said the cgroup and sched_ext dispatch-queue iterators look affected; Chen has already sent fixes for those. Starovoitov said the task VMA iterator has the same problem and does not hold the mmap lock across calls.