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

Message-ID: <CAJGXZLhL-LLjiA-ge8O5A5NDoZ5JABqZHqix0y-8ThcJjBSe=A@mail.gmail.com>
Date:   Fri, 24 Mar 2023 19:35:06 +0300
From:   Aleksey Shumnik <ashumnik9@...il.com>
To:     netdev@...r.kernel.org
Cc:     davem@...emloft.net, yoshfuji@...ux-ipv6.org, dsahern@...nel.org,
        pabeni@...hat.com, edumazet@...gle.com,
        Jakub Kicinski <kuba@...nel.org>, a@...table.cc,
        linux-kernel@...r.kernel.org
Subject: [BUG] gre interface incorrectly generates link-local addresses

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.