linux-kernel - Re: [PATCH RFC/RFT net-next v2 1/5] net: dsa: deny bridge VLAN with existing 8021q upper on any port

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aS8Q7yCvvhXn5iYu@horms.kernel.org>
Date: Tue, 2 Dec 2025 16:16:47 +0000
From: Simon Horman <horms@...nel.org>
To: Chris Mason <clm@...a.com>
Cc: Jonas Gorski <jonas.gorski@...il.com>, Andrew Lunn <andrew@...n.ch>,
	Vladimir Oltean <olteanv@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Shuah Khan <shuah@...nel.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Vladimir Oltean <vladimir.oltean@....com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH RFC/RFT net-next v2 1/5] net: dsa: deny bridge VLAN with
 existing 8021q upper on any port

On Mon, Dec 01, 2025 at 02:48:48PM -0800, Chris Mason wrote:
> On Mon, 1 Dec 2025 20:52:34 +0100 Jonas Gorski <jonas.gorski@...il.com> wrote:
> 
> > Hi,
> > 
> > On Mon, Dec 1, 2025 at 3:48 PM Simon Horman <horms@...nel.org> wrote:
> > >
> > > On Mon, Dec 01, 2025 at 11:28:13AM +0100, Jonas Gorski wrote:
> > >
> > > ...
> > >
> > > > diff --git a/net/dsa/user.c b/net/dsa/user.c
> > > > index f59d66f0975d..fa1fe0f1493a 100644
> > > > --- a/net/dsa/user.c
> > > > +++ b/net/dsa/user.c
> > > > @@ -653,21 +653,30 @@ static int dsa_user_port_attr_set(struct net_device *dev, const void *ctx,
> > > >
> > > >  /* Must be called under rcu_read_lock() */
> > > >  static int
> > > > -dsa_user_vlan_check_for_8021q_uppers(struct net_device *user,
> > > > +dsa_user_vlan_check_for_8021q_uppers(struct dsa_port *dp,
> > > >                                    const struct switchdev_obj_port_vlan *vlan)
> > > >  {
> > > > -     struct net_device *upper_dev;
> > > > -     struct list_head *iter;
> > > > +     struct dsa_switch *ds = dp->ds;
> > > > +     struct dsa_port *other_dp;
> > > >
> > > > -     netdev_for_each_upper_dev_rcu(user, upper_dev, iter) {
> > > > -             u16 vid;
> > > > +     dsa_switch_for_each_user_port(other_dp, ds) {
> > > > +             struct net_device *user = other_dp->user;
> > >
> > > Hi Jonas,
> > >
> > > The AI robot is concerned that user may be NULL here.
> > > And I can't convince myself that cannot be the case.
> > >
> > > Could you take a look?
> > >
> > > https://netdev-ai.bots.linux.dev/ai-review.html?id=47057e-e740-4b66-9d60-9ec2a7ee92a1#patch-0
> > 
> > At this point it can be NULL. But it being NULL is not an issue, as ...
> > >
> > > > +             struct net_device *upper_dev;
> > > > +             struct list_head *iter;
> > > >
> > > > -             if (!is_vlan_dev(upper_dev))
> > > > +             if (!dsa_port_bridge_same(dp, other_dp))
> > > >                       continue;
> > 
> > ... this condition will filter all cases where it is NULL. For
> > dsa_port_bridge_same() to return true both ports need to be attached
> > to a bridge (and to the same bridge), and to be attached to a bridge a
> > net_device is required, so other_dp->user cannot be NULL. And we only
> > access user after here.

Thanks for the explanation Jonas.

I wasn't very confident with this report.
And I was too focused on working out if user could be NULL rather
than if it matters. Still, I may not have worked it out.

> 
> I reproduced this false positive here, thanks for the explanation.  This is an
> example of a class of review mistakes I've wanted to fix, so I used it to
> improve the prompts around NULL pointers that are protected via other checks.
> 
> I'll test this on some more commits and push it out.

Thanks for following-up on this Chris.

I guess everyone has their own opinion on AI.
And, in a similar vein, many have opinions on the review-prompts.
But, FTR, I've been impressed by the output I've seen,
having used them for a few weeks now. And I look forward
to that improving further.