| 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
| ||
|
Date: Thu, 13 Apr 2023 00:33:59 +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 and maintainers,
Commit e5dd729460ca made it so the link local address for tunnels is
based on the source address of the tunnel instead of the eui64
algorithm. But it also broke changing addr_gen_mode to create the link
local address which is what my patch 23ca0c2c9340 aimed to fix.
If the last 4 bytes of a source ipv6 address are zero or in your case
where the ipv4 source address is not present "link/gre 0.0.0.0" then it
generates ipv6 link local addresses based on ipv4 addresses of all
other interfaces.
> > 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.
The simple fix for this to stop the for_each_netdev loop once one
address has been generated.
> > 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
Can you explain this in more detail or list some example network
services where this is a problem?
My understanding is that referencing link local address should be used
with an ifindex/name because of the local scope but not all software
enforces this.
The other solution to this is to move back to eui64 generation as was
the case before the changes in e5dd729460ca for gre/sit tunnels.
Regards,
Thomas Winter
On Fri, 2023-04-07 at 10:58 +1200, Thomas Winter wrote:
> 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