Re: [PATCH net] cipso: adjust cached option offsets when removing CIPSO

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 30 Sep 2026 23:04:00 +0900 Daehyeon Ko wrote:
> cipso_v4_skbuff_delattr() shifts every IPv4 option after CIPSO left by
> cipso_len, but leaves the cached srr, rr, ts and router_alert offsets at
> their old locations.
> 
> With a valid eight-byte CIPSO option followed by a seven-byte RR option,
> RR moves from offset 28 to 20 while opt->rr remains 28.  The stale offset
> then points into packet payload, letting the sender control both the
> length and bytes copied by __ip_options_echo().  Setting the length to
> 255 produced this condensed KASAN result:
> 
>   BUG: KASAN: stack-out-of-bounds in __ip_options_echo
>   Write of size 255
>   Call Trace:
>    __ip_options_echo
>    run_cipso_stale_offset [net_candidate_probe]
> 
> The destination holds 40 bytes of option data.  In an existing
> uninstrumented x86-64 v7.2 build, __icmp_send() places that buffer
> immediately before its stack canary, and the 255-byte copy also crosses
> the saved return address.  A canary mismatch unconditionally panics;
> no canary disclosure or control-flow exploit was demonstrated.
> 
> Mirror cipso_v4_delopt() and subtract cipso_len from each cached offset
> that follows CIPSO.  cipso_len is the logical distance moved by the first
> memmove(); hdr_len_delta includes padding, while the later header move and
> network-header reset relocate the bytes and their base together.
> 
> The adjusted input leaves rr at 20 with length 7 and completes without a
> sanitizer report.  Natural remote reachability requires a configured
> SELinux/NetLabel gateway and a later option consumer; the retained test
> invokes the real mutation and echo consumer directly because the available
> rootfs has no SELinux policy or netlabelctl.

AI points out that the example given can't happen in practice:

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260930140400.2955466-1-4ncienth@gmail.com

Please adjust the commit msg and the code per Ondrej's suggestion.
-- 
pw-bot: cr