From: Qi Tang <tpluszz77@gmail.com>
To: fw@strlen.de
Cc: jiayuan.chen@linux.dev, pablo@netfilter.org,
netfilter-devel@vger.kernel.org, davem@davemloft.net,
kuba@kernel.org, pabeni@redhat.com, edumazet@google.com,
netdev@vger.kernel.org, dsahern@kernel.org, idosch@nvidia.com,
horms@kernel.org, lyutoon@gmail.com, stable@vger.kernel.org,
Qi Tang <tpluszz77@gmail.com>
Subject: Re: [PATCH net] ipv4: validate ip_forward_options() option fields against skb tail
Date: Fri, 29 May 2026 18:43:56 +0800 [thread overview]
Message-ID: <20260529104356.911666-1-tpluszz77@gmail.com> (raw)
In-Reply-To: <ahlfI38aDciPfG2S@strlen.de>
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.
Thanks,
Qi
next prev parent reply other threads:[~2026-05-29 10:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 11:12 [PATCH net] ipv4: validate ip_forward_options() option fields against skb tail Qi Tang
2026-05-28 13:48 ` Jiayuan Chen
2026-05-28 16:32 ` Qi Tang
2026-05-29 2:55 ` Jiayuan Chen
2026-05-29 9:40 ` Florian Westphal
2026-05-29 10:43 ` Qi Tang [this message]
2026-05-31 12:17 ` Ido Schimmel
2026-06-04 8:46 ` Paolo Abeni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260529104356.911666-1-tpluszz77@gmail.com \
--to=tpluszz77@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=idosch@nvidia.com \
--cc=jiayuan.chen@linux.dev \
--cc=kuba@kernel.org \
--cc=lyutoon@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.