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

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

[Nuoqi Gui]

seg6_validate_srh() reads fixed SRH fields such as srh->type and
srh->hdrlen before checking that the supplied length covers the fixed
struct ipv6_sr_hdr fields.  Callers that pass a length smaller than
sizeof(struct ipv6_sr_hdr) therefore expose those reads to memory
outside the validated range.

The BPF SEG6 encap path (bpf_lwt_push_encap() -> bpf_push_seg6_encap())
is one such caller: it forwards a BPF program-supplied pointer and
length straight to seg6_validate_srh() with no minimum-size guard, so a
2-byte SEG6 encap header lets the validator read srh->type at offset 2
beyond the caller-supplied buffer.

Reject lengths shorter than the fixed SRH at the top of
seg6_validate_srh(), before any field is read.  This fixes the BPF helper
path and hardens the common validator for any other caller that reaches it
with a too-short SRH.

Fixes: fe94cc290f53 ("bpf: Add IPv6 Segment Routing helpers")
Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
---
 net/ipv6/seg6.c | 3 +++
 1 file changed, 3 insertions(+)

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;
 

---
base-commit: 96e7f9122aae0ed000ee321f324b812a447906d9
change-id: 20260619-f01-17-seg6-srh-len-a85f35427e0b

Best regards,
--  
Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>

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

[sashiko-bot]

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