From: Ido Schimmel <idosch@nvidia.com>
To: Zhiling Zou <zhilinz@nebusec.ai>
Cc: edumazet@google.com, netdev@vger.kernel.org, dsahern@kernel.org,
davem@davemloft.net, pabeni@redhat.com, horms@kernel.org,
leone4fernando@gmail.com, vega@nebusec.ai
Subject: Re: [PATCH net v6 1/1] ipmr: only copy pktinfo to cache reports
Date: Wed, 21 Oct 2026 10:26:45 +0300 [thread overview]
Message-ID: <20261021072645.GA3280290@shredder> (raw)
In-Reply-To: <0545f0c83f5ee2f6696210f87268e811ef655715.1792476357.git.zhilinz@nebusec.ai>
On Tue, Oct 20, 2026 at 02:39:36PM +0800, Zhiling Zou wrote:
> ipmr_cache_report() prepares IP_PKTINFO on the original skb. The
> ipv4_pktinfo_prepare() helper updates skb->cb and clears the pktinfo fields
> when packet info is disabled. Since the skb can continue through the data
> path, preserve and restore its original control block around the helper.
>
> The original implementation copies the entire control block to the report
> skb. For synthetic RTM_GETROUTE packets, NETLINK_CB data is interpreted as
> IPCB by the raw IPv4 receive path. With IP_RECVOPTS or IP_RETOPTS enabled,
> corrupted option offsets cause out-of-bounds reads or a stack buffer
> overflow. WHOLEPKT and WRVIFWHOLE reports also inherit stale IP option
> offsets when their header is prepended.
>
> Clear the report skb control block. Only prepare and copy pktinfo when the
> input skb has an IPv4 header. Synthetic route-query skbs use NETLINK_CB,
> not IPCB, so leave their report control block zeroed. Restore pkt->cb after
> preparing pktinfo for regular IPv4 packets.
>
> Fixes: bb7403655b3c ("ipmr: support IP_PKTINFO on cache report IGMP msg")
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Cc: stable@vger.kernel.org
> Reported-by: Vega <vega@nebusec.ai>
> Link: https://lore.kernel.org/netdev/20260903113055.GA90787@shredder/
> Suggested-by: Ido Schimmel <idosch@nvidia.com>
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Assisted-by: LLM
> Signed-off-by: Zhiling Zou <zhilinz@nebusec.ai>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
There are a few pre-existing issues that the AI review flagged. I will
take care of them.
next prev parent reply other threads:[~2026-10-21 7:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-20 6:39 [PATCH net v6 0/1] ipmr: only copy pktinfo to cache reports Zhiling Zou
2026-10-20 6:39 ` [PATCH net v6 1/1] " Zhiling Zou
2026-10-21 7:26 ` Ido Schimmel [this message]
2026-10-22 14:02 ` Eric Dumazet
2026-10-20 6:44 ` [PATCH net v6 0/1] " netdev-bot+sinfo
2026-10-23 19:30 ` patchwork-bot+netdevbpf
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=20261021072645.GA3280290@shredder \
--to=idosch@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=leone4fernando@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vega@nebusec.ai \
--cc=zhilinz@nebusec.ai \
/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.