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]/ Thanks
