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@xxxxxxxxx>
> > ---
> > 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
