Re: [RFC PATCH 07/13] udp_tunnel: remove the usage of the list iterator after the loop

[Dan Carpenter <dan.carpenter@oracle.com>]

On Wed, Feb 23, 2022 at 09:00:36PM +0100, Christophe JAILLET wrote:
> Le 17/02/2022 à 19:48, Jakob Koschel a écrit :
> > The usage of node->dev after the loop body is a legitimate type
> > confusion if the break was not hit. It will compare an undefined
> > memory location with dev that could potentially be equal. The value
> > of node->dev in this case could either be a random struct member of the
> > head element or an out-of-bounds value.
> > 
> > Therefore it is more safe to use the found variable. With the
> > introduction of speculative safe list iterator this check could be
> > replaced with if (!node).
> > 
> > Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
> > ---
> >   net/ipv4/udp_tunnel_nic.c | 7 +++++--
> >   1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/net/ipv4/udp_tunnel_nic.c b/net/ipv4/udp_tunnel_nic.c
> > index b91003538d87..c47f9fb36d29 100644
> > --- a/net/ipv4/udp_tunnel_nic.c
> > +++ b/net/ipv4/udp_tunnel_nic.c
> > @@ -842,11 +842,14 @@ udp_tunnel_nic_unregister(struct net_device *dev, struct udp_tunnel_nic *utn)
> >   	 */
> >   	if (info->shared) {
> >   		struct udp_tunnel_nic_shared_node *node, *first;
> > +		bool found = false;
> >   		list_for_each_entry(node, &info->shared->devices, list)
> > -			if (node->dev == dev)
> > +			if (node->dev == dev) {
> > +				found = true;
> >   				break;
> > -		if (node->dev != dev)
> > +			}
> > +		if (!found)
> >   			return;
> >   		list_del(&node->list);
> 
> Hi,
> 
> just in case, see Dan Carpeter's patch for the same issue with another fix
> at:
> https://lore.kernel.org/kernel-janitors/20220222134251.GA2271@kili/

Yeah.  My patch was already applied.

I've had an unpublished Smatch check for this for a while but I've been
re-writing it recently to make it more generic so that it worked for
all the different list_for_each type macros.  I'm going to publish it
soon.

Of course, all the real bugs are fixed so the remaining warnings are
false positives.

regards,
dan carpenter