* [PATCH] seg6: fix OOB read in advance_nextseg when segments_left is 0
@ 2026-10-28 11:31 Tang Bin
2026-10-28 11:35 ` netdev-bot+sinfo
2026-10-28 14:11 ` Gabriel Goller
0 siblings, 2 replies; 3+ messages in thread
From: Tang Bin @ 2026-10-28 11:31 UTC (permalink / raw)
To: andrea.mayer, davem, edumazet, kuba, pabeni, horms
Cc: netdev, linux-kernel, tangbin, stable
advance_nextseg() decrements srh->segments_left and uses it to index
srh->segments without checking it is non-zero. seg6_validate_srh() permits
segments_left == 0, so a packet with SRH segments_left==0 reaching an End*
action underflows the u8 (255) and reads srh->segments[255] (~4KB out of
bounds); the read bytes are then used as the new IPv6 destination address
(info leak) or crash on unmapped memory. The decap path
(decap_and_validate) already checks segments_left > 0, but the standard
End/End.X/End.T/End.B6.Encap/End.BPF paths do not. Reject segments_left ==
0 before decrementing.
Fixes: d7a669dd2f8b ("ipv6: sr: add helper functions for seg6local")
Cc: stable@vger.kernel.org
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
---
net/ipv6/seg6_local.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
index 53f7b2452..1d8312467 100644
--- a/net/ipv6/seg6_local.c
+++ b/net/ipv6/seg6_local.c
@@ -310,6 +310,10 @@ static struct ipv6_sr_hdr *advance_nextseg(struct sk_buff *skb,
/* skb_ensure_writable() may change skb pointers; evaluate srh again */
srh = (struct ipv6_sr_hdr *)(skb->data + srhoff);
+ if (srh->segments_left == 0) {
+ *reason = SKB_DROP_REASON_NOT_SPECIFIED;
+ return NULL;
+ }
srh->segments_left--;
addr = srh->segments + srh->segments_left;
ipv6_hdr(skb)->daddr = *addr;
--
2.52.0.windows.1
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] seg6: fix OOB read in advance_nextseg when segments_left is 0
2026-10-28 11:31 [PATCH] seg6: fix OOB read in advance_nextseg when segments_left is 0 Tang Bin
@ 2026-10-28 11:35 ` netdev-bot+sinfo
2026-10-28 14:11 ` Gabriel Goller
1 sibling, 0 replies; 3+ messages in thread
From: netdev-bot+sinfo @ 2026-10-28 11:35 UTC (permalink / raw)
To: Tang Bin
Cc: andrea.mayer, davem, edumazet, kuba, pabeni, horms, netdev,
linux-kernel, stable
Hi!
This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:
- How the issue was discovered, e.g. hit in production, hit during
development, syzbot report, manual code inspection, LLM or static
analysis tool scan.
- Whether the issue was actually triggered, or is only theoretical
(e.g. found by code inspection). If it was triggered please include
the symptoms, like the stack trace or error messages.
Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.
The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] seg6: fix OOB read in advance_nextseg when segments_left is 0
2026-10-28 11:31 [PATCH] seg6: fix OOB read in advance_nextseg when segments_left is 0 Tang Bin
2026-10-28 11:35 ` netdev-bot+sinfo
@ 2026-10-28 14:11 ` Gabriel Goller
1 sibling, 0 replies; 3+ messages in thread
From: Gabriel Goller @ 2026-10-28 14:11 UTC (permalink / raw)
To: Tang Bin
Cc: andrea.mayer, davem, edumazet, kuba, pabeni, horms, netdev,
linux-kernel, stable
On 28.10.2026 19:31, Tang Bin wrote:
> advance_nextseg() decrements srh->segments_left and uses it to index
> srh->segments without checking it is non-zero. seg6_validate_srh() permits
> segments_left == 0, so a packet with SRH segments_left==0 reaching an End*
> action underflows the u8 (255) and reads srh->segments[255] (~4KB out of
> bounds); the read bytes are then used as the new IPv6 destination address
> (info leak) or crash on unmapped memory. The decap path
> (decap_and_validate) already checks segments_left > 0, but the standard
> End/End.X/End.T/End.B6.Encap/End.BPF paths do not. Reject segments_left ==
> 0 before decrementing.
>
> Fixes: d7a669dd2f8b ("ipv6: sr: add helper functions for seg6local")
> Cc: stable@vger.kernel.org
> Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
> ---
> net/ipv6/seg6_local.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
> index 53f7b2452..1d8312467 100644
> --- a/net/ipv6/seg6_local.c
> +++ b/net/ipv6/seg6_local.c
> @@ -310,6 +310,10 @@ static struct ipv6_sr_hdr *advance_nextseg(struct sk_buff *skb,
> /* skb_ensure_writable() may change skb pointers; evaluate srh again */
> srh = (struct ipv6_sr_hdr *)(skb->data + srhoff);
>
> + if (srh->segments_left == 0) {
> + *reason = SKB_DROP_REASON_NOT_SPECIFIED;
> + return NULL;
> + }
> srh->segments_left--;
> addr = srh->segments + srh->segments_left;
> ipv6_hdr(skb)->daddr = *addr;
> --
> 2.52.0.windows.1
Can you show a codepath where it is possible to call advance_nextseg() with
srh->segments_left being 0?
End/End.X/End.T/End.B6.Encap/End.BPF behaviors call get_and_validate_srh(),
which calls seg6_get_srh(skb, IP6_FH_F_SKIP_RH), which uses ipv6_find_hdr(),
which skips all the segments_left=0 headers.
Thanks,
Gabriel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-28 14:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-28 11:31 [PATCH] seg6: fix OOB read in advance_nextseg when segments_left is 0 Tang Bin
2026-10-28 11:35 ` netdev-bot+sinfo
2026-10-28 14:11 ` Gabriel Goller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®