Merge branch 'bpf-memory-safety-lifetime-and-locking-fixes-followups'

Alexei Starovoitov says:

====================
bpf: Memory safety, lifetime and locking fixes (followups)

From: Alexei Starovoitov <ast@kernel.org>

The first 30 patches of v2 are applied. This is the rest of the series,
with what the reviews of v2 have found, and two fixes on top of patches
that are applied already. Most of the patches are from Josef.

Every bug was reproduced in a VM on top of bpf-next, on the kernel right
before and right after the patch that fixes it. The splats are in the
commit logs. That goes for what the reviews have found as well.

Programs that are attached to other programs:
  01 a tracing program with a target program passes for an iterator program
  02 extensions reach further into the context than their target
  04 extensions of functions that run sleepable
  11 extensions get the unclone prologue without an skb in R1

Lifetime of local storage, programs, sockets and devices:
  03 values of a dead owner are freed under sleepable programs
  05 the exception table of a program that still runs is not found
  06 BPF_PROG_TEST_RUN of sk_lookup uses the socket outside of RCU
  07 cpumap uses the device of a queued frame after it is gone

Dynptrs of packets, where a write can reallocate the head of the skb:
  08 kfuncs that write through a dynptr
  09 bpf_dynptr_write() in a global function
  10 a dynptr passed to a global function
  12 kfuncs that write through a dynptr do not unclone the skb
  13 the source of the write is a slice of the same skb
  14 overlapping source and destination in an skb
  15 overlapping source and destination in an xdp_buff
  16 slices as arguments of helpers that change the packet

Some of the fixes make the kernel refuse what it has accepted so far:

 - 01: a tracing program with BPF_TRACE_ITER cannot have a target program.
 - 02: an extension of a raw tracepoint, tracepoint or syscall program
   cannot be attached if it reaches further into the context than that
   program. A program that leaves the context to its extensions has to
   touch as much of it as they do.
 - 04: the main function of a sleepable program, and a global function that
   is called without the RCU read lock, cannot be extended. The
   summarization selftest is adjusted.
 - 08-10, 16: packet pointers and slices are invalidated in more places.
   That hits some programs which are harmless at run time. A program that
   keeps a packet pointer across a global function which only writes to a
   ringbuf dynptr is one example.
 - 11: an extension of a tc, lwt_xmit or sk_skb program that writes to
   packet data has to get the context as its first argument, and scalars
   beside it.

test_progs in its three flavors, test_maps and test_verifier show no new
failures. cpumask/test_insert_leave is flaky when the tests run in
parallel, with and without the series: its program does not check
is_test_task(), so any other fork in the system makes it fail.

veristat sees no difference for the 5691 programs of the selftests, nor for
the 466 programs of the sched_ext schedulers that BPF CI builds: same
verdicts, insns, states and stack depth.

v2 -> v3, after the reviews by sashiko and the BPF CI bot. The numbers in
brackets are those of v2:
 - rebased on top of patches 1-30
 - 01: new. A tracing program with attach_prog_fd got around [26].
 - 02: new. What [28] says of max_tp_access holds for max_ctx_offset too.
 - 03 [31]: map_free() took smap away from an element whose fields
   destroy() had left to the RCU Tasks Trace callback: they were leaked
 - 09 [37]: Fixes tag
 - 10 [38]: the dynptr of the bpf_user_ringbuf_drain() callback was taken
   for an argument of a global function
 - 11 [39]: look at the arguments only if there is a prologue. Extensions
   of XDP, sk_msg and sockopt programs were refused for no reason.
 - 14 [42], 16 [43]: commit logs
 - 15: new. XDP was missed in [42].
 - 05 [33], 07 [35]: no change. The symbols have to outlive the grace
   period, and an order 3 allocation per cpumap entry is fine.

Not in this version: the prologue of an extension can move the head of the
skb under the packet pointers of its caller, as sashiko has pointed out for
[39]. To count such an extension as one that changes packet data would
refuse what commit 7e40781cc8b7 ("bpf: verifier: Use target program's type
for access verifications") has made possible. That takes more thought.

v2: https://lore.kernel.org/bpf/20261017163745.3341787-1-alexei.starovoitov@gmail.com/
v1: https://lore.kernel.org/bpf/20261017012058.355787-1-alexei.starovoitov@gmail.com/
====================

Link: https://patch.msgid.link/20261017230950.802052-1-alexei.starovoitov@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>

0 files changed, 0 insertions, 0 deletions