Re: [PATCH net] seg6: validate SRH length before reading fixed fields

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Blind skb_pull() in __seg6_do_srh_inline() causes kernel panic on malformed or BPF-truncated packets.
--

commit a29767c35f1c85244acfe27c6f46d515a8b796c9
Author: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>

seg6: validate SRH length before reading fixed fields

This commit adds a minimum length check to seg6_validate_srh() before reading
fixed fields like srh->type. This prevents an out-of-bounds read when a BPF
program passes a truncated SEG6 encapsulation header.

> diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
> index 1c3ad25700c4c..d2cb32a1058af 100644
> --- a/net/ipv6/seg6.c
> +++ b/net/ipv6/seg6.c
> @@ -29,6 +29,9 @@ bool seg6_validate_srh(struct ipv6_sr_hdr *srh, int len, bool reduced)
>  	int max_last_entry;
>  	int trailing;
>  
> +	if (len < (int)sizeof(*srh))
> +		return false;
> +
>  	if (srh->type != IPV6_SRCRT_TYPE_4)
>  		return false;
>  

[Severity: High]
This is a pre-existing issue, but while looking at the BPF encap path
mentioned in the commit message, I noticed a potential panic in a related
function, __seg6_do_srh_inline(), when handling truncated packets.

If a BPF program at LWT_XMIT uses bpf_skb_change_tail() to truncate the packet
length to less than 40 bytes before calling bpf_lwt_push_encap() with
BPF_LWT_ENCAP_SEG6_INLINE, it seems we can hit a panic here:

net/ipv6/seg6_iptunnel.c:__seg6_do_srh_inline() {
	err = skb_cow_head(skb, hdrlen + dst_dev_overhead(cache_dst, skb));
	if (unlikely(err))
		return err;

	oldhdr = ipv6_hdr(skb);

	skb_pull(skb, sizeof(struct ipv6hdr));
	skb_postpull_rcsum(skb, skb_network_header(skb),
			   sizeof(struct ipv6hdr));

	skb_push(skb, sizeof(struct ipv6hdr) + hdrlen);
	...
}

skb_pull() will fail silently and return NULL without updating skb->data if
skb->len is less than sizeof(struct ipv6hdr).

Because skb_cow_head() only ensured hdrlen bytes of headroom, the subsequent
skb_push() for sizeof(struct ipv6hdr) + hdrlen will consume more headroom than
was allocated. Can this underflow the headroom and trigger skb_under_panic()?

Additionally, if the linear data length is less than 40 bytes but the total
length is greater, it looks like the internal __skb_pull() will cause skb->len
to fall below skb->data_len, which triggers a BUG() in net/core/skbuff.c.

Should there be a check to ensure skb->len is at least sizeof(struct ipv6hdr)
before calling skb_pull(), or does pskb_may_pull() need to be called earlier
in this path?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260620-f01-17-seg6-srh-len-v1-1-36cbb29c12f1@mails.tsinghua.edu.cn?part=1