Re: [PATCH net 1/1] ip6_tunnel: clear skb2->cb[] in ip6ip6_err()

[Ido Schimmel <idosch@nvidia.com>]

On Mon, Aug 03, 2026 at 02:12:33PM +0800, Zhiling Zou wrote:
> ip6ip6_err() clones an outer IPv6 ICMP error skb, pulls it to the
> quoted inner IPv6 packet, and then passes the clone to icmpv6_send().
> The clone still carries the outer packet's inet6_skb_parm in skb->cb.
> 
> If the outer packet had a Home Address Option, IP6CB(skb2)->dsthao
> remains non-zero after skb_pull(). icmpv6_send() later calls
> mip6_addr_swap(), which uses that stale dsthao offset against the quoted
> inner packet. A malformed inner destination-options header can then make
> the HAO lookup and address swap run past the end of the quoted packet
> and corrupt skb_shared_info.
> 
> Clear skb2->cb[] before pulling the quoted inner IPv6 packet so the
> reply path does not reuse metadata left by the outer IPv6 stack.
> 
> Fixes: e490d1d85cf5 ("[IPV6] IP6TUNNEL: Split out generic routine in ip6ip6_err().")
> Cc: stable@vger.kernel.org
> Reported-by: Vega <vega@nebusec.ai>
> Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>

Regarding:

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/fe1a5e765fbca88d69391887f0ed26a19e3e4d39.1785736562.git.zhilinz%40nebusec.ai

1. "Could this description be tightened up, given it is going to
stable?"

Nitpick.

2. "Is this the right commit to blame?"

Nitpick. We can blame 793832361fe7 ("[IPV6] MIP6: Revert address to send
ICMPv6 error."), but it doesn't matter in practice.

3. "Does clearing the whole inet6_skb_parm here also throw away IP6CB->iif,
which was valid and is still consumed by the reply path?"

Yes and it's fine. It needs to encode the iif of the packet that
icmpv6_send() is going to quote and it's not IP6CB->iif. It's
rt->dst.dev->ifindex, but passing 0 is legitimate.

4. "This isn't a bug introduced by this patch, but should the consumer be
hardened as well, rather than only this call site?"

Separate issue.

Reviewed-by: Ido Schimmel <idosch@nvidia.com>