On 2026/6/1 08:44, Alexei Starovoitov wrote: > On Fri, May 29, 2026 at 8:14 AM Leon Hwang <[email protected]> wrote: >> >> Sashiko pointed out [1]: >> The hdr pointer passed to bpf_lwt_push_ip_encap() can point to concurrently >> mutable memory such as a BPF map value. >> >> So, the memory of hdr pointer can be updated after skb_postpush_rcsum(). >> >> To fix it, memcpy() the hdr to a local buffer, which will be used for the >> following checks and updates. >> >> [1] https://lore.kernel.org/bpf/[email protected]/ >> >> Fixes: 52f278774e79 ("bpf: implement BPF_LWT_ENCAP_IP mode in >> bpf_lwt_push_encap") >> Signed-off-by: Leon Hwang <[email protected]> >> --- >> net/core/lwt_bpf.c | 7 +++++-- >> 1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c >> index f71ef82a5f3d..8009e427851f 100644 >> --- a/net/core/lwt_bpf.c >> +++ b/net/core/lwt_bpf.c >> @@ -599,6 +599,7 @@ static int handle_gso_encap(struct sk_buff *skb, bool >> ipv4, int encap_len) >> >> int bpf_lwt_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len, bool >> ingress) >> { >> + u8 buff[LWT_BPF_MAX_HEADROOM]; > > extra 256 bytes of stack to partially close a hypothetical issue > is not worth it. > Ignore such AI complaints. > 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. >
Ack. Will focus on the fix for encapsulating VxLAN in lwt. Thanks, Leon
