netdev - Re: [BUG] gre interface incorrectly generates link-local addresses

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: <CAJGXZLi7LedV_MYr==1RsN6goth73Y4txA=neci_QQcwa5Oqvw@mail.gmail.com>
Date:   Thu, 6 Apr 2023 18:04:35 +0300
From:   Aleksey Shumnik <ashumnik9@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, dsahern@...nel.org,
        pabeni@...hat.com, edumazet@...gle.com, a@...table.cc,
        Thomas.Winter@...iedtelesis.co.nz
Subject: Re: [BUG] gre interface incorrectly generates link-local addresses

Dear maintainers,

I remind you that the problem is still relevant.
The problem is not only in generating the number of link-local
addresses in an amount equal to the number of addresses on all
interfaces defined in /etc/network/interfaces before the gre
interface.
Due to the new method of link-local address generation, the same
link-local address may be formed on several gre interfaces, which may
lead to errors in the operation of some network services

Would you please answer the following questions
> Which linux distribution did you use when you found an error with the
> lack of link-local address generation on the gre interface?
> After fixing the error, only one link-local address is generated?
Is this a bug or an expected behavior?

On Sat, Mar 25, 2023 at 1:34 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> Adding Thomas as well.
>
> On Fri, 24 Mar 2023 19:35:06 +0300 Aleksey Shumnik wrote:
> > Dear Maintainers,
> >
> > I found that GRE arbitrarily hangs IP addresses from other interfaces
> > described in /etc/network/interfaces above itself (from bottom to
> > top). Moreover, this error occurs on both ip4gre and ip6gre.
> >
> > Example of mgre interface:
> >
> > 13: mgre1@...E: <MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc noqueue
> > state UNKNOWN group default qlen 1000
> >     link/gre 0.0.0.0 brd 0.0.0.0
> >     inet 10.10.10.100/8 brd 10.255.255.255 scope global mgre1
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::a0a:a64/64 scope link
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::7f00:1/64 scope host
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::a0:6842/64 scope host
> >        valid_lft forever preferred_lft forever
> >     inet6 fe80::c0a8:1264/64 scope host
> >        valid_lft forever preferred_lft forever
> >
> > It seems that after the corrections in the following commits
> > https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f
> > https://github.com/torvalds/linux/commit/30e2291f61f93f7132c060190f8360df52644ec1
> > https://github.com/torvalds/linux/commit/23ca0c2c93406bdb1150659e720bda1cec1fad04
> >
> > in function add_v4_addrs() instead of stopping after this check:
> >
> > if (addr.s6_addr32[3]) {
> >                 add_addr(idev, &addr, plen, scope, IFAPROT_UNSPEC);
> >                 addrconf_prefix_route(&addr, plen, 0, idev->dev, 0, pflags,
> >                                                                 GFP_KERNEL);
> >                  return;
> > }
> >
> > it goes further and in this cycle hangs addresses from all interfaces on the gre
> >
> > for_each_netdev(net, dev) {
> >       struct in_device *in_dev = __in_dev_get_rtnl(dev);
> >       if (in_dev && (dev->flags & IFF_UP)) {
> >       struct in_ifaddr *ifa;
> >       int flag = scope;
> >       in_dev_for_each_ifa_rtnl(ifa, in_dev) {
> >             addr.s6_addr32[3] = ifa->ifa_local;
> >             if (ifa->ifa_scope == RT_SCOPE_LINK)
> >                      continue;
> >             if (ifa->ifa_scope >= RT_SCOPE_HOST) {
> >                      if (idev->dev->flags&IFF_POINTOPOINT)
> >                               continue;
> >                      flag |= IFA_HOST;
> >             }
> >             add_addr(idev, &addr, plen, flag,
> >                                     IFAPROT_UNSPEC);
> >             addrconf_prefix_route(&addr, plen, 0, idev->dev,
> >                                      0, pflags, GFP_KERNEL);
> >             }
> > }
> >
> > Moreover, before switching to Debian 12 kernel version 6.1.15, I used
> > Debian 11 on 5.10.140, and there was no error described in the commit
> > https://github.com/torvalds/linux/commit/e5dd729460ca8d2da02028dbf264b65be8cd4b5f.
> > One link-local address was always generated on the gre interface,
> > regardless of whether the destination or the local address of the
> > tunnel was specified.
> >
> > Which linux distribution did you use when you found an error with the
> > lack of link-local address generation on the gre interface?
> > After fixing the error, only one link-local address is generated?
> > I think this is a bug and most likely the problem is in generating
> > dev->dev_addr, since link-local is formed from it.
> >
> > I suggest solving this problem or roll back the code changes made in
> > the comments above.
>