From: Hangbin Liu <liuhangbin@gmail.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Simon Horman <horms@kernel.org>,
MD Danish Anwar <danishanwar@ti.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Jaakko Karrenpalo <jkarrenpalo@gmail.com>,
Fernando Fernandez Mancera <ffmancera@riseup.net>,
Murali Karicheri <m-karicheri2@ti.com>,
WingMan Kwok <w-kwok2@ti.com>,
Stanislav Fomichev <sdf@fomichev.me>,
Xiao Liang <shaw.leon@gmail.com>,
Kuniyuki Iwashima <kuniyu@google.com>,
Johannes Berg <johannes.berg@intel.com>
Subject: Re: [PATCHv2 net] hsr: use proper locking when iterating over ports
Date: Thu, 28 Aug 2025 09:52:48 +0000 [thread overview]
Message-ID: <aLAm8Fka8E19JOay@fedora> (raw)
In-Reply-To: <147f016f-bf5e-4cb6-80a7-192db0ff62c4@redhat.com>
On Thu, Aug 28, 2025 at 11:19:11AM +0200, Paolo Abeni wrote:
> On 8/27/25 11:33 AM, Hangbin Liu wrote:
> > @@ -672,9 +672,13 @@ struct net_device *hsr_get_port_ndev(struct net_device *ndev,
> > struct hsr_priv *hsr = netdev_priv(ndev);
> > struct hsr_port *port;
> >
> > + rcu_read_lock();
> > hsr_for_each_port(hsr, port)
> > - if (port->type == pt)
> > + if (port->type == pt) {
> > + rcu_read_unlock();
> > return port->dev;
>
> This is not good enough. At this point accessing `port` could still
> cause UaF;
>
> The only callers, in icssg_prueth_hsr_{add,del}_mcast(), can be either
> under the RTNL lock or not. A safer option would be acquiring a
> reference on dev before releasing the rcu lock and let the caller drop
> such reference
OK, thanks for the suggestion.
>
> > + }
> > + rcu_read_unlock();
> > return NULL;
> > }
> > EXPORT_SYMBOL(hsr_get_port_ndev);
> > diff --git a/net/hsr/hsr_main.c b/net/hsr/hsr_main.c
> > index 192893c3f2ec..eec6e20a8494 100644
> > --- a/net/hsr/hsr_main.c
> > +++ b/net/hsr/hsr_main.c
> > @@ -22,9 +22,13 @@ static bool hsr_slave_empty(struct hsr_priv *hsr)
> > {
> > struct hsr_port *port;
> >
> > + rcu_read_lock();
> > hsr_for_each_port(hsr, port)
> > - if (port->type != HSR_PT_MASTER)
> > + if (port->type != HSR_PT_MASTER) {
> > + rcu_read_unlock();
> > return false;
> > + }
> > + rcu_read_unlock();
> > return true;
> > }
>
> AFAICS the only caller of this helper is under the RTNL lock
Thanks, sometimes I not very sure if the caller is under RTNL lock or not.
Is there a good way to check this?
>
> > @@ -134,9 +138,13 @@ struct hsr_port *hsr_port_get_hsr(struct hsr_priv *hsr, enum hsr_port_type pt)
> > {
> > struct hsr_port *port;
> >
> > + rcu_read_lock();
> > hsr_for_each_port(hsr, port)
> > - if (port->type == pt)
> > + if (port->type == pt) {
> > + rcu_read_unlock();
> > return port;
>
> The above is not enough.
>
> AFAICS some/most caller are already either under the RTNL lock or the
> rcu lock.
>
> I think it would be better rename the hsr_for_each_port_rtnl() helper to
> hsr_for_each_port_rcu(), retaining the current semantic, use it here,
> and fix the caller as needed.
Do you mean to modify like
#define hsr_for_each_port(hsr, port) \
list_for_each_entry_rcu((port), &(hsr)->ports, port_list)
+#define hsr_for_each_port_rcu(hsr, port) \
+ list_for_each_entry_rcu((port), &(hsr)->ports, port_list, lockdep_rtnl_is_held())
I'm not sure if the naming is clear. e.g. rcu_dereference_rtnl() also use rtnl
suffix to check if rtnl is held.
>
> It will be useful to somehow split the patch in a series, as it's
> already quite big and will increase even more.
OK.
Thanks
Hangbin
>
> /P
>
next prev parent reply other threads:[~2025-08-28 9:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-27 9:33 [PATCHv2 net] hsr: use proper locking when iterating over ports Hangbin Liu
2025-08-28 9:19 ` Paolo Abeni
2025-08-28 9:52 ` Hangbin Liu [this message]
2025-08-28 10:40 ` 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=aLAm8Fka8E19JOay@fedora \
--to=liuhangbin@gmail.com \
--cc=aleksander.lobakin@intel.com \
--cc=danishanwar@ti.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=ffmancera@riseup.net \
--cc=horms@kernel.org \
--cc=jkarrenpalo@gmail.com \
--cc=johannes.berg@intel.com \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=m-karicheri2@ti.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=shaw.leon@gmail.com \
--cc=w-kwok2@ti.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.