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
| ||
|
Message-ID: <be4cd6bf2103caa42f475739a3dc6a841e1c6542.camel@alliedtelesis.co.nz> Date: Thu, 6 Apr 2023 22:59:33 +0000 From: Thomas Winter <Thomas.Winter@...iedtelesis.co.nz> To: "ashumnik9@...il.com" <ashumnik9@...il.com>, "kuba@...nel.org" <kuba@...nel.org> CC: "edumazet@...gle.com" <edumazet@...gle.com>, "dsahern@...nel.org" <dsahern@...nel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "davem@...emloft.net" <davem@...emloft.net>, "pabeni@...hat.com" <pabeni@...hat.com>, "a@...table.cc" <a@...table.cc> Subject: Re: [BUG] gre interface incorrectly generates link-local addresses Hello Aleksey, Sorry, I was on leave during March so only getting to this now. I will have a proper look at this when I get back to work on Tuesday and try to reproduce your issue. My issue was on our routers using kernel 5.15.89 and we don't use /etc/network/interfaces for configuration. The tunnel was created with netlink messages like with the "ip link" command and an IPv6 link local address is generated by setting /proc/sys/net/ipv6/conf/tunnel0/addr_gen_mode but this broke after commit e5dd729460ca. I did not see any hanging addresses like you described. Regards, Thomas On Thu, 2023-04-06 at 18:04 +0300, Aleksey Shumnik wrote: > 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, > > > G > > > FP_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.
Powered by blists - more mailing lists