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.
