Re: [PATCH net] ipv4: validate ip_forward_options() option fields against skb tail

[Ido Schimmel <idosch@nvidia.com>]

On Fri, May 29, 2026 at 06:43:56PM +0800, Qi Tang wrote:
> Florian Westphal <fw@strlen.de> wrote:
> > I'm not sure netfilter is the only facility that can munge data this
> > way nowadays.  The plan is to disable arbitrary network header rewrites:
> >
> > https://lore.kernel.org/netfilter-devel/20260527121147.22076-1-fw@strlen.de/
> 
> Agreed, the source side is the better place for this on mainline.
> 
> I went looking for other ways into the window between option compile
> (ip_rcv_options() in ip_rcv_finish_core, after PREROUTING) and
> ip_forward_options(), and only found nft_payload and nfqueue at the
> FORWARD hook. tc/cls-act run before compile (ingress) or after
> ip_forward_options (egress), BPF at the netfilter hook can't write the
> packet (base helpers only, no bpf_skb_store_bytes), and the LWT_IN BPF
> path is blocked by the verifier. So your two-part restriction closes the
> only in-tree triggers I could find.
> 
> This is just one consumer of the pattern; __ip_options_echo(),
> ipmr_cache_report() and the CIPSO/CALIPSO netlbl_skbuff_getattr() path
> are the same, posted as a series here:
> 
>   https://lore.kernel.org/netdev/20260524041442.2432071-1-tpluszz77@gmail.com/
> 
> so if the source-side restriction is the way to go it probably makes
> more sense to drop these consumer-side checks than to fix each site.
> Your call.

FWIW, I agree that it would be better to go with Florian's patches
rather than always assuming that we can't trust the data that was parsed
from the IP options.