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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ