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  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 14:28:11 -0600
From:	David Stevens <>
To:	David Miller <>
Subject: Re: [PATCH net] net: vxlan: fix crash when interface is created with no

-----David Miller <> wrote: -----

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

I never tried it, but as there are IP-version-specific processing (the
whole reason we need to check to support both), I'd expect
that before the v6 support patch, v6-encapsulated packets would have
been dropped, or at least mishandled. We accepted all v4 packets,
because v4 is all that was supported.

I think the biggest risk is that someone who is only using or
caring about v4 will have a security vulnerability because
someone can drop packets on the virtual network via v6--
something likely unexpected on an otherwise v4-only network.

When the default_dst is a v4 multicast, or saddr is set to be
a v4 address, we can't have 2-way communication with other
segments using v6, and similary if they are v6, a v4-endpoint
can't join the v6-multicast group.

I think mixing protocols only makes sense when saddr is not
set at all and when default_dst is not a multicast address.
The other possibilities lead to unexpected problems, and
potential mischief.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists