linux-kernel - Re: [PATCH 1/2] ip/ip6_gre: Fix changing addr gen mode not generating IPv6 link local address

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] [day] [month] [year] [list]

Message-ID: <97d9344408b6c0909680a13f4d76ce51dbb064cb.camel@alliedtelesis.co.nz>
Date:   Tue, 3 Jan 2023 22:28:45 +0000
From:   Thomas Winter <Thomas.Winter@...iedtelesis.co.nz>
To:     "davem@...emloft.net" <davem@...emloft.net>,
        "dsahern@...nel.org" <dsahern@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
        "a@...table.cc" <a@...table.cc>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>
Subject: Re: [PATCH 1/2] ip/ip6_gre: Fix changing addr gen mode not generating
 IPv6 link local address

On Tue, 2022-12-20 at 14:16 +0100, Paolo Abeni wrote:
> On Mon, 2022-12-19 at 14:06 +1300, Thomas Winter wrote:
> > Commit e5dd729460ca changed the code path so that GRE tunnels
> > generate an IPv6 address based on the tunnel source address.
> > It also changed the code path so GRE tunnels don't call
> > addrconf_addr_gen
> > in addrconf_dev_config which is called by
> > addrconf_sysctl_addr_gen_mode
> > when the IN6_ADDR_GEN_MODE is changed.
> > 
> > This patch aims to fix this issue by moving the code in
> > addrconf_notify
> > which calls the addr gen for GRE and SIT into a separate function
> > and calling it in the places that expect the IPv6 address to be
> > generated.
> > 
> > The previous addrconf_dev_config is renamed to addrconf_eth_config
> > since it only expected eth type interfaces and follows the
> > addrconf_gre/sit_config format.
> > 
> > Fixes: e5dd729460ca ("ip/ip6_gre: use the same logic as SIT
> > interfaces when computing v6LL address")
> > Signed-off-by: Thomas Winter <Thomas.Winter@...iedtelesis.co.nz>
> > ---
> >  net/ipv6/addrconf.c | 47 +++++++++++++++++++++++++--------------
> > ------
> >  1 file changed, 26 insertions(+), 21 deletions(-)
> > 
> > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> > index 6dcf034835ec..e9d7ec03316d 100644
> > --- a/net/ipv6/addrconf.c
> > +++ b/net/ipv6/addrconf.c
> > @@ -3355,7 +3355,7 @@ static void addrconf_addr_gen(struct
> > inet6_dev *idev, bool prefix_route)
> >  	}
> >  }
> >  
> > -static void addrconf_dev_config(struct net_device *dev)
> > +static void addrconf_eth_config(struct net_device *dev)
> 
> You are creating a new function with the name of an existing one,
> while
> renaming the latter. IMHO this makes the patch hard to review as
> there
> are some existing call side for the old name, which we likelly want
> to
> explicitly see here.
> 

Perhaps these functions can be named something like
"addrconfig_init_auto_addrs".

> >  {
> >  	struct inet6_dev *idev;
> >  
> > @@ -3447,6 +3447,30 @@ static void addrconf_gre_config(struct
> > net_device *dev)
> >  }
> >  #endif
> >  
> > +static void addrconf_dev_config(struct net_device *dev)
> > +{
> > +	switch (dev->type) {
> > +#if IS_ENABLED(CONFIG_IPV6_SIT)
> > +	case ARPHRD_SIT:
> > +		addrconf_sit_config(dev);
> > +		break;
> > +#endif
> > +#if IS_ENABLED(CONFIG_NET_IPGRE) || IS_ENABLED(CONFIG_IPV6_GRE)
> > +	case ARPHRD_IP6GRE:
> > +	case ARPHRD_IPGRE:
> > +		addrconf_gre_config(dev);
> > +		break;
> > +#endif
> > +	case ARPHRD_LOOPBACK:
> > +		init_loopback(dev);
> > +		break;
> 
> If I read correctly, this change will cause unneeded attempt to re-
> add
> the loopback address on the loopback device when the lo.addr_gen_mode
> sysfs entry is touched. I think such side effect should be avoided.

My understanding is that these addresses should always exist. It
doesn't look like any problem will happen if the loopback address
already exists and this called.

> 
> Thanks,
> 
> Paolo
>