Re: [PATCH net v2] ipv6: do not let ipv6_find_hdr() return an offset past the packet end

[Ido Schimmel <idosch@nvidia.com>]

On Wed, Sep 16, 2026 at 09:57:53PM +0200, Norbert Szetei wrote:
> ipv6_find_hdr() walks the extension header chain, skipping each header by
> the length that header itself declares.  ipv6_optlen() returns up to 2048,
> and the skip is never checked against skb->len, so the offset stored in
> *offset can point past the end of the packet.
> 
> openvswitch installs that offset as the transport header, and
> update_ipv6_checksum() then reads and writes the transport checksum field
> out of bounds:
> 
>   BUG: KASAN: slab-use-after-free in inet_proto_csum_replace16+0x445/0x470
>   Read of size 2 at addr ffff88810b754b06 by task ovs_ipv6_oob/629
>   CPU: 4 UID: 1000 PID: 629 Comm: ovs_ipv6_oob Tainted: G N 7.3.0-rc3+ #348
>   Call Trace:
>    inet_proto_csum_replace16+0x445/0x470
>    set_ipv6_addr+0x3dd/0x460
>    do_execute_actions+0x6a3d/0x7c40
>    ovs_execute_actions+0xfd/0x480
>    ovs_packet_cmd_execute+0xc38/0xf20
>    genl_rcv_msg+0x59e/0x870
>    netlink_rcv_skb+0x18b/0x450
>    genl_rcv+0x2d/0x40
>    netlink_unicast+0x6bc/0xa20
> 
>   The buggy address belongs to the object at ffff88810b754980
>    which belongs to the cache skbuff_small_head of size 704
>   The buggy address is located 390 bytes inside of
>    freed 704-byte region [ffff88810b754980, ffff88810b754c40)
> 
> Other callers use that offset too, so bound it here rather than in one
> caller.
> 
> Reject a header whose declared length does not fit in the packet.
> ipv6_find_hdr() already fails with -EBADMSG on a malformed chain, so this
> adds no new failure mode.
> 
> Fixes: f8f626754ebe ("ipv6: Move ipv6_find_hdr() out of Netfilter code.")

Blaming b777e0ce7437 would be more accurate, but it doesn't matter in
practice given that f8f626754ebe is from 2012.

> Suggested-by: Ilya Maximets <i.maximets@ovn.org>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Norbert Szetei <norbert@doyensec.com>

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