[PATCH] ipv6: seg6: clear IPv4 control block in End.DT4

David Lee posted 1 patch 2 months ago
There is a newer version of this series
net/ipv6/seg6_local.c | 3 +++
1 file changed, 3 insertions(+)
[PATCH] ipv6: seg6: clear IPv4 control block in End.DT4
Posted by David Lee 2 months ago
The End.DT4 input path decapsulates an IPv4 packet and sends it
directly to ip_route_input() and dst_input(). It therefore bypasses
ip_rcv_core(), which normally clears IPCB. The skb still contains
IP6CB data from the outer packet, and IPv6 extension-header offsets
overlap the IPv4 option fields. This can make __ip_options_echo()
copy beyond the allocation for saved options.

Clear IPCB after validating the inner IPv4 header and preserve the
ingress interface as ip_rcv_core() does. This prevents outer IPv6
metadata from being interpreted as inner IPv4 options.

Fixes: 664d6f86868b ("seg6: add support for the SRv6 End.DT4 behavior")
Bug found and triaged by OpenAI Security Research and 
validated by Trail of Bits.

Assisted-by: Codex:gpt-5.6-sol gpt-5.5-cyber
Signed-off-by: Kyle Zeng <kylebot@openai.com>
---
Trail of Bits has a reproducer for this bug that triggers a KASAN
slab-out-of-bounds write in __ip_options_echo() and can share if needed.

 net/ipv6/seg6_local.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
index 2b41e4c0d..d03b377f5 100644
--- a/net/ipv6/seg6_local.c
+++ b/net/ipv6/seg6_local.c
@@ -1186,6 +1186,9 @@ static int input_action_end_dt4(struct sk_buff *skb,
 	if (!pskb_may_pull(skb, sizeof(struct iphdr)))
 		goto drop;
 
+	memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
+	IPCB(skb)->iif = skb->skb_iif;
+
 	skb = end_dt_vrf_core(skb, slwt, AF_INET);
 	if (!skb)
 		/* packet has been processed and consumed by the VRF */
Re: [PATCH] ipv6: seg6: clear IPv4 control block in End.DT4
Posted by Jakub Kicinski 2 months ago
On Fri, 31 Jul 2026 14:08:32 +0000 David Lee wrote:
> Bug found and triaged by OpenAI Security Research and 
> validated by Trail of Bits.

Please delete this ad from the commit msg.
Maybe you want to put Reported-by: Kyle .. @open.ai>
And you are sending the patch so that will be the trailofbits.

Please learn to use correct authorship tags (From vs SoB).
-- 
pw-bot: cr
Re: [PATCH] ipv6: seg6: clear IPv4 control block in End.DT4
Posted by Nicolas Dichtel 2 months ago
Le 31/07/2026 à 16:08, David Lee a écrit :
> The End.DT4 input path decapsulates an IPv4 packet and sends it
> directly to ip_route_input() and dst_input(). It therefore bypasses
> ip_rcv_core(), which normally clears IPCB. The skb still contains
> IP6CB data from the outer packet, and IPv6 extension-header offsets
> overlap the IPv4 option fields. This can make __ip_options_echo()
> copy beyond the allocation for saved options.
> 
> Clear IPCB after validating the inner IPv4 header and preserve the
> ingress interface as ip_rcv_core() does. This prevents outer IPv6
> metadata from being interpreted as inner IPv4 options.
> 
> Fixes: 664d6f86868b ("seg6: add support for the SRv6 End.DT4 behavior")
> Bug found and triaged by OpenAI Security Research and 
> validated by Trail of Bits.

There should be no empty line between tags.

> 
> Assisted-by: Codex:gpt-5.6-sol gpt-5.5-cyber
> Signed-off-by: Kyle Zeng <kylebot@openai.com>
> ---
> Trail of Bits has a reproducer for this bug that triggers a KASAN
> slab-out-of-bounds write in __ip_options_echo() and can share if needed.
> 
>  net/ipv6/seg6_local.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
> index 2b41e4c0d..d03b377f5 100644
> --- a/net/ipv6/seg6_local.c
> +++ b/net/ipv6/seg6_local.c
> @@ -1186,6 +1186,9 @@ static int input_action_end_dt4(struct sk_buff *skb,
>  	if (!pskb_may_pull(skb, sizeof(struct iphdr)))
>  		goto drop;
>  
> +	memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
> +	IPCB(skb)->iif = skb->skb_iif;
> +
>  	skb = end_dt_vrf_core(skb, slwt, AF_INET);
>  	if (!skb)
>  		/* packet has been processed and consumed by the VRF */
> 

End.DX4 also calls ip_route_input(). I guess the same problem exists. Am I wrong?

Regards,
Nicolas