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? 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).
