On Mon, Jun 8, 2026 at 2:26 PM Alexei Starovoitov <[email protected]> wrote: > > On Mon, Jun 8, 2026 at 1:55 PM Kuniyuki Iwashima <[email protected]> wrote: > > > > On Mon, Jun 8, 2026 at 1:02 PM Alexei Starovoitov > > <[email protected]> wrote: > > > > > > On Mon Jun 8, 2026 at 10:21 AM PDT, Kuniyuki Iwashima wrote: > > > > On Mon, Jun 8, 2026 at 5:59 AM Jiayuan Chen <[email protected]> > > > > wrote: > > > >> > > > >> bpf_sk_assign_tcp_reqsk() can assign a TCP reqsk to a non-TCP skb, > > > >> causing a panic when the skb enters the wrong L4 receive path [1]. > > > >> An initial attempt tried to fix this in the BPF helper by checking > > > >> iph->protocol, but Sashiko [2] revealed that BPF programs can bypass > > > >> this check via a TOCTOU attack by modifying iph->protocol around the > > > >> call: > > > >> > > > >> iph->protocol = IPPROTO_TCP; > > > >> bpf_sk_assign_tcp_reqsk(udp_skb, tcp_sk); > > > >> iph->protocol = IPPROTO_UDP; > > > >> > > > >> Furthermore, bpf_sk_assign() has had the same class of vulnerability > > > >> since its introduction — it can assign any socket type to any skb > > > >> without protocol validation. Since the BPF helper check alone cannot > > > >> prevent a malicious BPF program from crashing the kernel, add protocol > > > > > > > > I'm curious about the BPF maintainers' stance on this kind of "bug" > > > > where admin tries to shoot oneself in the foot. > > > > > > > > I saw Alexei said this recently, and I guess it applies here as well ? > > > > https://lore.kernel.org/bpf/CAADnVQLh7VEKAtckzz=xovpt8ovpdqshvppcwhdqu2owqx2...@mail.gmail.com/ > > > > > > > > ---8<--- > > > > Not every "bug" needs a fix. > > > > If a malicious bpf user wants to crash the kernel they will > > > > find a way to do so. Especially with agents. > > > > We cannot realistically close all of the holes. > > > > Right now the priority is to fix the issues that normal > > > > users can hit and not bots. > > > > ---8<--- > > > > > > In addition to that I have to add that skb_steal_sock() is performance > > > critical path of networking stack. Adding runtime overheard there > > > because bots can find a way to abuse the interfaces is not a good trade > > > off. > > > If there is no simple way to fix it completely on the bpf side > > > then we have to flag this issue as "won't fix" and move on. > > > > I asked if we could fix this in the verifier but it seems difficult. [0] > > Since this is triggered only by BPF misuse, treating it as "won't fix" > > makes more sense to me. > > > > [0]: https://lore.kernel.org/all/[email protected]/ > > btw is earlier sashiko TOCTOU concern real?
Yes, the selftest in patch 2 should reproduce null-ptr-deref. (I tested one in a prior version) > iph->protocol = IPPROTO_TCP; > bpf_sk_assign_tcp_reqsk(udp_skb, tcp_sk); > iph->protocol = IPPROTO_UDP; > > as far as I can tell past bpf_sk_assign_tcp_reqsk() > the networking stack only looks at skb->protocol, > so modifying iph->protocol will only mess up > things on the wire (if this packet goes out). ip_rcv_finish_core() uses iph->protocol for early demux and ip_local_deliver_finish() also uses it for demux.
