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>, John Heffner <jheffner@psc.edu>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH net] ipv4: Fix device use-after-free in ip_skb_dst_mtu()
Date: Mon, 28 Sep 2026 15:34:11 +0300 [thread overview]
Message-ID: <20260928123411.GA440063@shredder> (raw)
In-Reply-To: <20260927071051.3693368-1-nicoyip.dev@gmail.com>
On Sun, Sep 27, 2026 at 03:10:51PM +0800, Chengfeng Ye wrote:
> When a socket ignores the path MTU, ip_skb_dst_mtu() reads the device
> MTU without RCU protection. The multicast and broadcast output path
> through ip_mc_output() can reach this helper without an RCU read lock.
> Netfilter releases its internal read lock before calling
> ip_finish_output().
>
> A sender can load dst->dev and then be preempted before reading dev->mtu.
> Concurrent device unregistration replaces dst->dev with blackhole_netdev
> and drops the old device reference. After the grace period and remaining
> references drain, the device can be freed before the sender resumes and
> reads its MTU, causing a use-after-free.
>
> 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
>
> Allocated by task 97:
> __kvmalloc_node_noprof+0x1d4/0x620
> alloc_netdev_mqs+0x81/0x12c0
> rtnl_create_link+0xaa3/0xe30
> rtnl_newlink+0xabc/0x1f70
>
> 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 device lookup and MTU read with RCU and use dst_dev_rcu() to
> access the device pointer. Keep the MTU limit and headroom calculation
> unchanged.
This still leaves other potential UAFs in the ip_mc_output() path.
Better to fix it by adding an RCU read-side critical section in
ip_mc_output() in a similar fashion to its unicast counterpart. See
commit 1dbf1d590d10 ("net: Add locking to protect skb->dev access in
ip_output"). You can blame 4a6ce2b6f2ec ("net: introduce a new function
dst_dev_put()").
next prev parent reply other threads:[~2026-09-28 12:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-27 7:10 Chengfeng Ye
2026-09-28 3:17 ` Hangbin Liu
2026-09-28 12:34 ` Ido Schimmel [this message]
2026-09-28 16:29 ` Chengfeng Ye
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=20260928123411.GA440063@shredder \
--to=idosch@nvidia.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jheffner@psc.edu \
--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 \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®