From: Simon Horman <horms@kernel.org>
To: kuniyu@google.com
Cc: Simon Horman <horms@kernel.org>,
edumazet@google.com, pabeni@redhat.com, dsahern@kernel.org,
netdev@vger.kernel.org, kuba@kernel.org, davem@davemloft.net,
kuni1840@gmail.com
Subject: Re: [v3,net-next,08/15] ipmr: Move unregister_netdevice_many() out of ipmr_free_table().
Date: Mon, 2 Mar 2026 13:12:19 +0000 [thread overview]
Message-ID: <20260302131218.679806-2-horms@kernel.org> (raw)
In-Reply-To: <20260228221800.1082070-9-kuniyu@google.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
ipmr: Move unregister_netdevice_many() out of ipmr_free_table().
This commit refactors network device cleanup in the IP multicast routing
code by moving unregister_netdevice_many() from ipmr_free_table() to its
callers, enabling batched cleanup across multiple tables per netns.
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index d15e05662b09..7e2aa2026f01 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
[ ... ]
> @@ -349,8 +355,13 @@ static int __net_init ipmr_rules_init(struct net *net)
>
> static void __net_exit ipmr_rules_exit(struct net *net)
> {
> + LIST_HEAD(dev_kill_list);
> +
> ASSERT_RTNL();
> - ipmr_free_table(net->ipv4.mrt);
> +
> + ipmr_free_table(net->ipv4.mrt, &dev_kill_list);
> + unregister_netdevice_many(&dev_kill_list);
> +
> net->ipv4.mrt = NULL;
> }
In the !CONFIG_IP_MROUTE_MULTIPLE_TABLES version of ipmr_rules_exit(),
does this sequence lead to a use-after-free?
ipmr_free_table() calls kfree(mrt) to free the table:
net/ipv4/ipmr.c:ipmr_free_table() {
...
rhltable_destroy(&mrt->mfc_hash);
kfree(mrt);
}
Then unregister_netdevice_many() is called, which triggers NETDEV_UNREGISTER
notifications. The global notifier ipmr_device_event() handles this event
and calls ipmr_for_each_table().
In the non-MULTIPLE_TABLES case, ipmr_for_each_table() expands to:
for (mrt = net->ipv4.mrt; mrt; mrt = NULL)
Since net->ipv4.mrt still points to the freed memory at this point (it's
only set to NULL after unregister_netdevice_many() completes), won't
ipmr_device_event() access mrt->vif_table and mrt->maxvif from a freed
slab object?
The CONFIG_IP_MROUTE_MULTIPLE_TABLES version appears safe because
list_del(&mrt->list) removes the table from the iteration list before
kfree().
Should net->ipv4.mrt = NULL be moved before calling
unregister_netdevice_many(), or before calling ipmr_free_table()?
> @@ -425,18 +436,16 @@ static struct mr_table *ipmr_new_table(struct net *net, u32 id)
> ipmr_expire_process, ipmr_new_table_set);
> }
>
> -static void ipmr_free_table(struct mr_table *mrt)
> +static void ipmr_free_table(struct mr_table *mrt, struct list_head *dev_kill_list)
> {
> struct net *net = read_pnet(&mrt->net);
> - LIST_HEAD(dev_kill_list);
>
> WARN_ON_ONCE(!mr_can_free_table(net));
>
> timer_shutdown_sync(&mrt->ipmr_expire_timer);
> mroute_clean_tables(mrt, MRT_FLUSH_VIFS | MRT_FLUSH_VIFS_STATIC |
> MRT_FLUSH_MFC | MRT_FLUSH_MFC_STATIC,
> - &dev_kill_list);
> - unregister_netdevice_many(&dev_kill_list);
> + dev_kill_list);
> rhltable_destroy(&mrt->mfc_hash);
> kfree(mrt);
> }
next prev parent reply other threads:[~2026-03-02 13:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-28 22:17 [PATCH v3 net-next 00/15] ipmr: No RTNL for RTNL_FAMILY_IPMR rtnetlink Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 01/15] selftest: net: Add basic functionality tests for ipmr Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 02/15] ipmr: Annotate access to mrt->mroute_do_{pim,assert,wrvifwhole} Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 03/15] ipmr: Convert ipmr_rtm_dumplink() to RCU Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 04/15] ipmr: Use MAXVIFS in mroute_msgsize() Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 05/15] ipmr: Convert ipmr_rtm_getroute() to RCU Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 06/15] ipmr: Convert ipmr_rtm_dumproute() " Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 07/15] ipmr: Move unregister_netdevice_many() out of mroute_clean_tables() Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 08/15] ipmr: Move unregister_netdevice_many() out of ipmr_free_table() Kuniyuki Iwashima
2026-03-02 13:12 ` Simon Horman [this message]
2026-03-02 19:04 ` [v3,net-next,08/15] " Kuniyuki Iwashima
2026-03-02 19:24 ` Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 09/15] ipmr: Convert ipmr_net_exit_batch() to ->exit_rtnl() Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 10/15] ipmr: Remove RTNL in ipmr_rules_init() and ipmr_net_init() Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 11/15] ipmr: Call fib_rules_unregister() without RTNL Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 12/15] ipmr: Define net->ipv4.{ipmr_notifier_ops,ipmr_seq} under CONFIG_IP_MROUTE Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 13/15] ipmr/ip6mr: Convert net->ipv[46].ipmr_seq to atomic_t Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 14/15] ipmr: Add dedicated mutex for mrt->{mfc_hash,mfc_cache_list} Kuniyuki Iwashima
2026-02-28 22:17 ` [PATCH v3 net-next 15/15] ipmr: Don't hold RTNL for ipmr_rtm_route() Kuniyuki Iwashima
2026-03-03 4:47 ` [PATCH v3 net-next 00/15] ipmr: No RTNL for RTNL_FAMILY_IPMR rtnetlink 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=20260302131218.679806-2-horms@kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=kuni1840@gmail.com \
--cc=kuniyu@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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.