From: Ido Schimmel <idosch@nvidia.com>
To: Chengfeng Ye <nicoyip.dev@gmail.com>
Cc: David Ahern <dsahern@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>, Martin KaFai Lau <kafai@fb.com>,
Wei Wang <weiwan@google.com>, Hangbin Liu <hangbin.liu@linux.dev>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH net v2] ipv4: Fix device use-after-free in ip_mc_output()
Date: Tue, 29 Sep 2026 19:36:14 +0300 [thread overview]
Message-ID: <20260929163614.GA905623@shredder> (raw)
In-Reply-To: <20260928162534.2122207-1-nicoyip.dev@gmail.com>
On Tue, Sep 29, 2026 at 12:25:34AM +0800, Chengfeng Ye wrote:
> ip_mc_output() reads rt->dst.dev and stores it in skb->dev without RCU
> protection. dst_dev_put() can concurrently replace the destination device
It can also be rt_flush_dev(), if the dst entry is uncached.
> and release the old device after an RCU grace period, leaving the multicast
The reference release is immediate, only the free happens after a GP.
> output path with a stale skb->dev.
>
> The stale device can be dereferenced by the post-routing path. In
> particular, a socket using IP_PMTUDISC_PROBE reaches ip_skb_dst_mtu() from
> ip_finish_output() and reads the freed device's MTU.
ip_skb_dst_mtu() reads the device from the dst entry, not from skb->dev.
>
> KASAN reported:
>
> BUG: KASAN: slab-use-after-free in ip_skb_dst_mtu+0x634/0x740
> Read of size 4 at addr ffff88810921c038 by task poc/98
> Call Trace:
> ip_skb_dst_mtu+0x634/0x740
> __ip_finish_output.part.0+0x22/0x2c0
> ip_mc_output+0x287/0x930
> ip_send_skb+0x11d/0x150
> udp_send_skb+0x63e/0xdf0
> udp_sendmsg+0x1235/0x1da0
> __sys_sendto+0x32c/0x3a0
>
> Freed by task 99:
> kfree+0x131/0x3c0
> device_release+0xc8/0x240
> kobject_put+0x14d/0x280
> netdev_run_todo+0x4cb/0xc70
> rtnl_dellink+0x362/0xa90
>
> Protect the whole multicast output path with an RCU read-side critical
> section, as ip_output() already does. Load the destination device through
> skb_dst_dev_rcu() and keep it protected through the post-routing hooks and
> ip_finish_output().
>
> Fixes: 4a6ce2b6f2ec ("net: introduce a new function dst_dev_put()")
> Cc: stable@vger.kernel.org
> Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
> ---
> Changes in v2:
> - Protect the whole ip_mc_output() path instead of only the MTU read.
> - Load the destination device with skb_dst_dev_rcu(), matching ip_output().
> - Use the commit that made dst device replacement RCU-protected as Fixes.
>
> Link: https://lore.kernel.org/r/20260927071051.3693368-1-nicoyip.dev@gmail.com/ [v1]
>
> net/ipv4/ip_output.c | 19 +++++++++++++------
> 1 file changed, 13 insertions(+), 6 deletions(-)
The diff itself looks fine.
FTR, I'm aware of the discussion that wants an RCU critical section in
ip_local_out(), but:
1. Adding one in ip_mc_output() is consistent with other output
functions: ip_output(), ip6_output(), ip_mr_output(), ip6_mr_output(),
etc.
2. This patch doesn't affect the fast path, unlike an RCU critical
section in ip_local_out() [1].
3. Patching ip_local_out() doesn't cover all the process context callers
of dst_output() either.
And yes, I'm aware that more places suffer from this "problem". I opened
an internal ticket after seeing [2]. I will get to it eventually and
will target it at net-next since these UAFs are not very realistic as
evident from [2].
[1] https://lore.kernel.org/netdev/85c6016d-fb15-4c61-aab9-61448911f934@redhat.com/
[2] https://lore.kernel.org/netdev/20260819164528.3761320-1-jjy600901@snu.ac.kr/
prev parent reply other threads:[~2026-09-29 16:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 16:25 [PATCH net v2] ipv4: Fix device use-after-free in ip_mc_output() Chengfeng Ye
2026-09-29 8:37 ` Antoine Tenart
2026-09-29 9:42 ` Jiayuan Chen
2026-09-29 16:36 ` Ido Schimmel [this message]
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=20260929163614.GA905623@shredder \
--to=idosch@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=hangbin.liu@linux.dev \
--cc=horms@kernel.org \
--cc=kafai@fb.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nicoyip.dev@gmail.com \
--cc=pabeni@redhat.com \
--cc=stable@vger.kernel.org \
--cc=weiwan@google.com \
/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.