Re: [PATCH net] bpf: lwt: clear stale IP control block after pushing an encap header
From: Xiang Mei <hidden>
Date: 2026-09-16 07:32:52
Also in:
bpf, lkml, stable
On Tue, Sep 15, 2026 at 9:11 PM Xiang Mei [off-list ref] wrote:
quoted hunk ↗ jump to hunk
bpf_lwt_push_ip_encap() prepends an encapsulation header and calls skb_reset_network_header(), but leaves the IP control block describing the inner header. Its offsets are relative to the network header, so they now point into the encapsulated packet. On an ingress lwt-bpf encap route a forwarded packet carrying a Record Route option then reaches __ip_options_echo() with a stale opt->rr. It takes the option length from the packet and copies up to 255 bytes into the fixed-size option storage on the __icmp_send() stack. ip_forward_options() writes at a packet-controlled offset for the same reason. Clear the stale state once the outer header is in place, as the tunnel encapsulators do and as seg6_local.c was taught to do in commit f967455fb2a5 ("seg6: reset IP6CB after IPv6 decapsulation") and commit 44930446dde4 ("ipv6: seg6: clear IPv4 control block on IPIP decapsulation"). BUG: KASAN: stack-out-of-bounds in __ip_options_echo (net/ipv4/ip_options.c:96) Write of size 255 at addr ffff8880bee08930 by task exploit/150 Call Trace: <IRQ> __asan_memcpy (mm/kasan/shadow.c:106) __ip_options_echo (net/ipv4/ip_options.c:96) __icmp_send (net/ipv4/icmp.c:949) ip_forward (./include/net/icmp.h:43 net/ipv4/ip_forward.c:176) lwtunnel_input (net/core/lwtunnel.c:465) ip_rcv (net/ipv4/ip_input.c:612) __netif_receive_skb_one_core (net/core/dev.c:6264) process_backlog (net/core/dev.c:6728) __napi_poll (net/core/dev.c:7787) net_rx_action (net/core/dev.c:8007) handle_softirqs (kernel/softirq.c:645) do_softirq.part.0 (kernel/softirq.c:546) </IRQ> __local_bh_enable_ip (kernel/softirq.c:473) __dev_queue_xmit (net/core/dev.c:4961) packet_sendmsg (net/packet/af_packet.c:3143) __sys_sendto (net/socket.c:2281) __x64_sys_sendto (net/socket.c:2288) do_syscall_64 (arch/x86/entry/syscall_64.c:84) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Cc: stable@vger.kernel.org Fixes: 52f278774e79 ("bpf: implement BPF_LWT_ENCAP_IP mode in bpf_lwt_push_encap") Reported-by: <redacted> Assisted-by: LLM Signed-off-by: Xiang Mei <redacted> --- net/core/lwt_bpf.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c index da49364ec63d..17be476b5717 100644 --- a/net/core/lwt_bpf.c +++ b/net/core/lwt_bpf.c@@ -649,6 +649,18 @@ int bpf_lwt_push_ip_encap(struct sk_buff *skb, void *hdr, u32 len, bool ingress) if (ingress) skb_postpush_rcsum(skb, iph, len); skb_reset_network_header(skb); + if (ipv4) { + memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt)); + } else { + bool l3slave = ipv6_l3mdev_skb(IP6CB(skb)->flags); + int iif = IP6CB(skb)->iif; + + memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); + IP6CB(skb)->iif = iif; + IP6CB(skb)->nhoff = offsetof(struct ipv6hdr, nexthdr); + if (l3slave) + IP6CB(skb)->flags |= IP6SKB_L3SLAVE; + } if (is_udp_tunnel) { size_t iph_sz = ipv4 ? iph->ihl * 4 : sizeof(struct ipv6hdr); --2.43.0
I just found Weiming post a patch solving same problem: https://lore.kernel.org/bpf/20260915170147.3943392-2-bestswngs@gmail.com/ (local) and that patch covers the cases I didn't consider so please ignore this patch. Thanks, Xiang