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

[Andrea Mayer <andrea.mayer@uniroma2.it>]

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>