[PATCH net v4] ipv6: seg6: clear IPv4 control block on IPIP decapsulation

[PATCH net v4] ipv6: seg6: clear IPv4 control block on IPIP decapsulation

[David Lee]

From: Kyle Zeng <kylebot@openai.com>

End.DX4 and End.DT4 decapsulate an IPv4 packet through
decap_and_validate() and send it directly to IPv4 routing. The inner
packet therefore bypasses ip_rcv_core(), which normally clears IPCB
before IPv4 interprets skb->cb.

The skb instead retains IP6CB data from the outer packet. IP6CB and
IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps
IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and
ts.

The sender can make the stale optlen byte nonzero with a valid outer
extension-header chain. The reproducers put an eight-byte Destination
Options header immediately after the 40-byte IPv6 header and before the
Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled
Destination Options offset in both lastopt and nhoff, setting them to
40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees
optlen = 40 and rr = 40.

Both tcp_v4_save_options() and __ip_options_echo() skip option copying
when optlen is zero. Here optlen is 40, so the TCP SYN path allocates
room for 40 bytes of option data and calls __ip_options_echo(). The
stale rr value makes that function read inner packet byte 41 as the
Record Route option length. The reproducers set that sender-controlled
byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte
option-data area.

Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5
kernel both produced:

  BUG: KASAN: slab-out-of-bounds in __ip_options_echo()
  Write of size 255

The relevant End.DX4 call path is:

  __ip_options_echo
  tcp_v4_route_req
  tcp_conn_request
  tcp_v4_conn_request
  tcp_rcv_state_process
  tcp_v4_do_rcv
  tcp_v4_rcv
  ip_protocol_deliver_rcu
  ip_local_deliver_finish
  ip_local_deliver
  input_action_end_dx4_finish
  input_action_end_dx4

The relevant End.DT4 call path is:

  __ip_options_echo
  tcp_v4_route_req
  tcp_conn_request
  tcp_v4_conn_request
  tcp_rcv_state_process
  tcp_v4_do_rcv
  tcp_v4_rcv
  ip_protocol_deliver_rcu
  ip_local_deliver_finish
  ip_local_deliver
  input_action_end_dt4

tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so
it does not appear as a separate frame.

When decap_and_validate() handles IPPROTO_IPIP, save the ingress
interface from IP6CB, clear IPCB, and restore the saved value. Doing
this in the common decapsulation path covers End.DX4, End.DT4, and
End.DT46's IPv4 arm.

Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after
l3mdev processing, which can replace skb_iif with the L3 master;
IP6CB iif still records the receiving interface set at IPv6 ingress.

Fixes: 891ef8dd2a8d ("ipv6: sr: implement additional seg6local actions")
Cc: stable@vger.kernel.org
Suggested-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber
Signed-off-by: Kyle Zeng <kylebot@openai.com>
Co-developed-by: David Lee <david.lee@trailofbits.com>
Signed-off-by: David Lee <david.lee@trailofbits.com>
---
Changes in v4:
- Explain how the stale occurs.
- Include the observed End.DX4 and End.DT4 call paths.

v3: https://lore.kernel.org/netdev/20260810154732.850472-1-david.lee@trailofbits.com/

Changes in v3:
- Clear IPCB in the common IPPROTO_IPIP decapsulation path so End.DX4,
  End.DT4, and End.DT46's IPv4 arm are covered.
- Preserve the ingress interface from IP6CB instead of skb->skb_iif,
  which can identify the VRF master after l3mdev processing.
- Update the Fixes tag to the commit that introduced End.DX4.
- Include the End.DX4 and End.DT4 KASAN evidence.

v2: https://lore.kernel.org/netdev/20260804094625.715305-1-david.lee@trailofbits.com/
v1: https://lore.kernel.org/all/20260731140832.567669-1-david.lee@trailofbits.com/

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

diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
index 2b41e4c0dddd..95ea0b62729a 100644
--- a/net/ipv6/seg6_local.c
+++ b/net/ipv6/seg6_local.c
@@ -256,6 +256,13 @@ static bool decap_and_validate(struct sk_buff *skb, int proto)
 	if (iptunnel_pull_offloads(skb))
 		return false;
 
+	if (proto == IPPROTO_IPIP) {
+		int iif = IP6CB(skb)->iif;
+
+		memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
+		IPCB(skb)->iif = iif;
+	}
+
 	return true;
 }
 
-- 
2.53.0

Re: [PATCH net v4] ipv6: seg6: clear IPv4 control block on IPIP decapsulation

[Andrea Mayer]

On Mon, 17 Aug 2026 08:58:38 +0000
David Lee <david.lee@trailofbits.com> wrote:

Thanks for the v4.

> From: Kyle Zeng <kylebot@openai.com>
>
> End.DX4 and End.DT4 decapsulate an IPv4 packet through
> decap_and_validate() and send it directly to IPv4 routing. The inner
> packet therefore bypasses ip_rcv_core(), which normally clears IPCB
> before IPv4 interprets skb->cb.
>
> The skb instead retains IP6CB data from the outer packet. IP6CB and
> IPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps
> IPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and
> ts.
>
> The sender can make the stale optlen byte nonzero with a valid outer
> extension-header chain. The reproducers put an eight-byte Destination
> Options header immediately after the 40-byte IPv6 header and before the
> Segment Routing Header. ipv6_destopt_rcv() records the sender-controlled
> Destination Options offset in both lastopt and nhoff, setting them to
> 40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees
> optlen = 40 and rr = 40.
>
> Both tcp_v4_save_options() and __ip_options_echo() skip option copying
> when optlen is zero. Here optlen is 40, so the TCP SYN path allocates
> room for 40 bytes of option data and calls __ip_options_echo(). The
> stale rr value makes that function read inner packet byte 41 as the
> Record Route option length. The reproducers set that sender-controlled
> byte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte
> option-data area.
>
> Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5
> kernel both produced:
>
>   BUG: KASAN: slab-out-of-bounds in __ip_options_echo()
>   Write of size 255
>
> The relevant End.DX4 call path is:
>
>   __ip_options_echo
>   tcp_v4_route_req
>   tcp_conn_request
>   tcp_v4_conn_request
>   tcp_rcv_state_process
>   tcp_v4_do_rcv
>   tcp_v4_rcv
>   ip_protocol_deliver_rcu
>   ip_local_deliver_finish
>   ip_local_deliver
>   input_action_end_dx4_finish
>   input_action_end_dx4
>
> The relevant End.DT4 call path is:
>
>   __ip_options_echo
>   tcp_v4_route_req
>   tcp_conn_request
>   tcp_v4_conn_request
>   tcp_rcv_state_process
>   tcp_v4_do_rcv
>   tcp_v4_rcv
>   ip_protocol_deliver_rcu
>   ip_local_deliver_finish
>   ip_local_deliver
>   input_action_end_dt4
>
> tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so
> it does not appear as a separate frame.
>

Nit, not worth a respin: the two call paths are the same from
__ip_options_echo() to ip_local_deliver(), so one of them, plus the
frames after ip_local_deliver() for the other, would do.

> When decap_and_validate() handles IPPROTO_IPIP, save the ingress
> interface from IP6CB, clear IPCB, and restore the saved value. Doing
> this in the common decapsulation path covers End.DX4, End.DT4, and
> End.DT46's IPv4 arm.
>
> Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after
> l3mdev processing, which can replace skb_iif with the L3 master;
> IP6CB iif still records the receiving interface set at IPv6 ingress.
>
> Fixes: 891ef8dd2a8d ("ipv6: sr: implement additional seg6local actions")
> Cc: stable@vger.kernel.org
> Suggested-by: Andrea Mayer <andrea.mayer@uniroma2.it>
> Assisted-by: Codex:gpt-5.6-sol Codex:gpt-5.5-cyber
> Signed-off-by: Kyle Zeng <kylebot@openai.com>
> Co-developed-by: David Lee <david.lee@trailofbits.com>
> Signed-off-by: David Lee <david.lee@trailofbits.com>
> ---
> Changes in v4:
> - Explain how the stale occurs.
> - Include the observed End.DX4 and End.DT4 call paths.
>
> v3: https://lore.kernel.org/netdev/20260810154732.850472-1-david.lee@trailofbits.com/
>
> Changes in v3:
> - Clear IPCB in the common IPPROTO_IPIP decapsulation path so End.DX4,
>   End.DT4, and End.DT46's IPv4 arm are covered.
> - Preserve the ingress interface from IP6CB instead of skb->skb_iif,
>   which can identify the VRF master after l3mdev processing.
> - Update the Fixes tag to the commit that introduced End.DX4.
> - Include the End.DX4 and End.DT4 KASAN evidence.
>
> v2: https://lore.kernel.org/netdev/20260804094625.715305-1-david.lee@trailofbits.com/
> v1: https://lore.kernel.org/all/20260731140832.567669-1-david.lee@trailofbits.com/
>
>  net/ipv6/seg6_local.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>

Side note: before your patch IPSKB_L3SLAVE could read as set inside
the IPCB() on this path by chance (even with no VRF involved),
depending on how the outer IPv6 packet was fragmented:
IPCB->flags overlaps the outer IP6CB->frag_max_size (with
CONFIG_IPV6_MIP6).

Your patch clears IPCB->flags, which loses nothing: that bit did not
record an enslavement to a VRF; it was stale outer data.
And on End.DX4 nothing records one in the inner packet's IPCB.
That is a different bug from the out-of-bounds write you are fixing.

In other words, on End.DX4 the IPSKB_L3SLAVE propagation was missing
before this patch, and this patch sanitizes garbage that could have
accidentally set that bit. IMHO, the propagation should go in its
own patch. I will look at it.

Reviewed-by: Andrea Mayer <andrea.mayer@uniroma2.it>

Re: [PATCH net v4] ipv6: seg6: clear IPv4 control block on IPIP decapsulation

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Mon, 17 Aug 2026 08:58:38 +0000 you wrote:
> From: Kyle Zeng <kylebot@openai.com>
> 
> End.DX4 and End.DT4 decapsulate an IPv4 packet through
> decap_and_validate() and send it directly to IPv4 routing. The inner
> packet therefore bypasses ip_rcv_core(), which normally clears IPCB
> before IPv4 interprets skb->cb.
> 
> [...]

Here is the summary with links:
  - [net,v4] ipv6: seg6: clear IPv4 control block on IPIP decapsulation
    https://git.kernel.org/netdev/net/c/44930446dde4

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html