Re: [PATCH net] bpf: lwt: clear stale IP control block after pushing an encap header

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: type confusion in bpf_lwt_push_ip_encap drops VRF association
--

commit ca07a1fe3610a67c27699bc32edbe202fd703034
Author: Xiang Mei <xmei5@asu.edu>

bpf: lwt: clear stale IP control block after pushing an encap header

This patch clears the stale IP control block in bpf_lwt_push_ip_encap()
after pushing an encapsulation header. It zeroes the options for IPv4
and re-initializes the control block for IPv6 while preserving the iif
and l3slave flags to prevent out-of-bounds reads.

> diff --git a/net/core/lwt_bpf.c b/net/core/lwt_bpf.c
> index da49364ec63de..17be476b57172 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));

[Severity: High]
This is a pre-existing issue, but does this leave the IPv4 control flags
uninitialized when encapsulating an inner IPv6 packet with an outer IPv4
header?

The memset clears the IP options (offsets 4-43 of skb->cb), but leaves
IPCB(skb)->flags (at offset 44) untouched. For inner IPv6 packets, the
control block was inet6_skb_parm (24 bytes), so offsets 24-47 were never
cleared during ip6_rcv_core() and might contain arbitrary garbage from
previous layers.

Could the outer IPv4 packet inherit this garbage in IPCB(skb)->flags,
potentially setting critical routing flags like IPSKB_FORWARDED,
IPSKB_XFRM_TRANSFORMED, or IPSKB_L3SLAVE randomly?

> +	} else {
> +		bool l3slave = ipv6_l3mdev_skb(IP6CB(skb)->flags);

[Severity: Medium]
When encapsulating an inner IPv4 packet with an outer IPv6 header, the code
evaluates ipv4 as false (since the outer header is IPv6) and reads
ipv6_l3mdev_skb(IP6CB(skb)->flags) to preserve the VRF association.

Because the inner packet was IPv4, does IP6CB (offset 16) alias with the
inner packet's IP options (IPCB(skb)->opt) rather than actual IPv6 flags?

This type confusion means the legitimate IPSKB_L3SLAVE flag of the inner
IPv4 packet (at offset 44) is completely ignored, and the l3slave variable
will always evaluate to false. Does this cause the packet to silently lose
its VRF association?

> +		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);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916041102.1914333-1-xmei5@asu.edu?part=1