netdev - Re: [PATCH v2] ip_vti: Fix 'ip tunnel add' with 'key' parameters

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 11 Jun 2014 00:31:17 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ixaphire@...tor.net
Cc:	kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
	kaber@...sh.net, steffen.klassert@...unet.com,
	herbert@...dor.apana.org.au, sergei.shtylyov@...entembedded.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] ip_vti: Fix 'ip tunnel add' with 'key' parameters

From: Dmitry Popov <ixaphire@...tor.net>
Date: Sun, 8 Jun 2014 02:06:25 +0400

> ip tunnel add remote 10.2.2.1 local 10.2.2.2 mode vti ikey 1 okey 2
> translates to p->iflags = VTI_ISVTI|GRE_KEY and p->i_key = 1, but GRE_KEY !=
> TUNNEL_KEY, so ip_tunnel_ioctl would set i_key to 0 (same story with o_key) 
> making us unable to create vti tunnels with [io]key via ip tunnel.
> 
> We cannot simply translate GRE_KEY to TUNNEL_KEY (as GRE module does) because 
> vti_tunnels with same local/remote addresses but different ikeys will be treated
> as different then. So, imo the best option here is to move p->i_flags & *_KEY 
> check for vti tunnels from ip_tunnel.c to ip_vti.c and to think about [io]_mark
> field for ip_tunnel_parm in the future.
> 
> Signed-off-by: Dmitry Popov <ixaphire@...tor.net>

Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html