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

Message-ID: <4af69c165836c2e22217341c4a64228bcd43a877.camel@alliedtelesis.co.nz>
Date: Wed, 7 Feb 2024 22:05:35 +0000
From: Thomas Winter <Thomas.Winter@...iedtelesis.co.nz>
To: "jansaley@...il.com" <jansaley@...il.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>
CC: "pabeni@...hat.com" <pabeni@...hat.com>, "dsahern@...nel.org"
	<dsahern@...nel.org>, "a@...table.cc" <a@...table.cc>, "davem@...emloft.net"
	<davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>
Subject: Re: [BUG] gre interface incorrectly generates link-local addresses

Hello,

On Fri, 2024-02-02 at 13:01 +0000, Антарио Просперо wrote:
> Hell
> I want to bring up this topic again
> Is it possible to use the addr_gen_mode parameter for GRE in the
> current version of addrconf?

Short answer, no.

> There was an edit in the e5dd729460ca commit that dev->interface type
> should be equal to ARPHRD_ETHER, then addrconf_addr_gen will be
> called.
> But doesn't this contradict the fact that before calling the
> addrconf_gre_config function, there is a check that dev->type should
> be equal to ARPHRD_IPGRE or ARPHRD_IP6GRE?

Commit e5dd729460ca broke the addrconf_addr_gen sysctl value generating
a link local address for GRE tunnels which our userspace was relying
on. My commits 30e2291f61f9 and 23ca0c2c9340 attempted to resolve this
by making addrconf_gre_config get called
by addrconf_sysctl_addr_gen_mode with the new
function addrconf_init_auto_addrs which will call addrconf_gre_config.

I tried to keep the new functionality from e5dd729460ca intact so
addrconf_addr_gen is still called only when dev->type == ARPHRD_ETHER
which means that the type of address generation
(eg IN6_ADDR_GEN_MODE_RANDOM or IN6_ADDR_GEN_MODE_EUI64) is not not
considered when the type is ARPHRD_IPGRE or ARPHRD_IP6GRE instead the
address will be generated based on another interface with add_v4_addrs.