netdev - [PATCH net] ipv6: addrconf: fix Juniper SSL VPN client regression

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

Message-Id: <1468098791-20420-1-git-send-email-bjorn@mork.no>
Date:	Sat,  9 Jul 2016 23:13:11 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	netdev@...r.kernel.org
Cc:	Valdis Kletnieks <Valdis.Kletnieks@...edu>,
	Jonas Lippuner <jonas@...puner.ca>,
	Bjørn Mork <bjorn@...k.no>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	吉藤英明 
	<hideaki.yoshifuji@...aclelinux.com>
Subject: [PATCH net] ipv6: addrconf: fix Juniper SSL VPN client regression

The Juniper SSL VPN client use a "tun" interface and seems to
be picky about visible changes.to it. Commit cc9da6cc4f56
("ipv6: addrconf: use stable address generator for ARPHRD_NONE")
made such interfaces get an auto-generated IPv6 link local address
by default, similar to most other interface types. This made the
Juniper SSL VPN client fail for unknown reasons.

Fixing this regression by effectively reverting the behaviour to
what we had before, while keeping the new "addrgenmode random"
feature.

This will cause a regression for any userspace application which
has started to depend on the new behaviour.  But it is still
considered the lesser evil, considering the short period this
behaviour has been default.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=121131
Fixes: cc9da6cc4f56 ("ipv6: addrconf: use stable address generator for ARPHRD_NONE")
Reported-by: Valdis Kletnieks <Valdis.Kletnieks@...edu>
Reported-and-tested-by: Jonas Lippuner <jonas@...puner.ca>
Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc: 吉藤英明 <hideaki.yoshifuji@...aclelinux.com>
Signed-off-by: Bjørn Mork <bjorn@...k.no>
---
Valdis,

I know you reported this regression back in April, but I never
saw any answers to Hannes' and mine followup quesions so I forgot
all about it.  Sorry about that.  Could you test this patch and
see if it works for you too?

Bjørn

 net/ipv6/addrconf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 47f837a58e0a..34e80c6aa810 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3120,7 +3120,7 @@ static void addrconf_dev_config(struct net_device *dev)
 	/* this device type has no EUI support */
 	if (dev->type == ARPHRD_NONE &&
 	    idev->addr_gen_mode == IN6_ADDR_GEN_MODE_EUI64)
-		idev->addr_gen_mode = IN6_ADDR_GEN_MODE_RANDOM;
+		idev->addr_gen_mode = IN6_ADDR_GEN_MODE_NONE;

 	addrconf_addr_gen(idev, false);
 }
-- 
2.8.1