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] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 19 Mar 2014 15:46:49 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	mike.rapoport@...ellosystems.com
Cc:	dlstevens@...ibm.com, netdev@...r.kernel.org
Subject: Re: [PATCH net] net: vxlan: fix crash when interface is created
 with no group

From: Mike Rapoport <mike.rapoport@...ellosystems.com>
Date: Wed, 19 Mar 2014 09:14:46 +0200

> On Tue, Mar 18, 2014 at 10:55:16AM -0600, David Stevens wrote:
>>
>> Wouldn't it be better to:
>>
>> 1) make sure all of vxlan_dev is initialized before use,
>> especially default_dst
>> 2) change the v6 code to check for AF_INET6 too, and do
>> nothing if not set. If not set by the admin, the family of
>> default_dst would then be AF_UNSPEC and not match.
> 
> The family of default dst is implicitly initailized to AF_UNSPEC because
> if kzalloc :)
> 
> I agree that explicit check for AF_INET6 is much better than fallthrough
> with simple 'else' clause and I can send a patch that makes the checks
> for IPv6 as well as default_dst initialization explicit
> 
> However, for the particular case in vxlan_rcv, checking the packet
> version seems to me semantically more correct than comparing default_dst
> protocol family with AF_INET or AF_INET6.

The way I read things, we would receive packets unconditionally in the
pre-ipv6-support code.  So we have to keep doing so.

Therefore we either have to check the SKB protocol or pass an explicit
protocol as an argument to vs->rcv(...).

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ