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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 23 Mar 2014 22:09:33 -0700 From: Pravin Shelar <pshelar@...ira.com> To: Mike Rapoport <mike.rapoport@...ellosystems.com> Cc: David Stevens <dlstevens@...ibm.com>, David Miller <davem@...emloft.net>, netdev <netdev@...r.kernel.org> Subject: Re: [PATCH net] net: vxlan: fix crash when interface is created with no group On Sun, Mar 23, 2014 at 2:27 AM, Mike Rapoport <mike.rapoport@...ellosystems.com> wrote: > On Fri, Mar 21, 2014 at 05:22:06AM -0600, David Stevens wrote: >> -----Mike Rapoport <mike.rapoport@...ellosystems.com> wrote: ----- >> >> >Checking skb->protocol will drop ARP requests. What about using >> >ip_hdr(skb)->version? >> >> Mike, ip_hdr() here is the outer packet, so it's got to be a UDP packet-- >> we just don't know if it's UDP/IP or UDP/IPv6 when it is bound to INADDR_ANY, >> since both can be delivered. It could use version in this case, because >> both possible protocols have version in the same place, but I think it's >> more correct to use the MAC layer protocol rather than relying on the >> fact that IPv4 and IPv6 have "version" in the same spot. "It could be ARP" >> would be the argument for NOT using the version in places where it really >> could be ARP, even though that isn't the case here. >> >> vxlan_rcv() is only called for VXLAN encapsulated packets sent to the bound >> UDP port. >> >> So, if "vs->family" holds the one we want to support, we can't just blindly >> assume the received packet is IPv4, for example, and start accessing >> IPv4 fields, because it could be an IPv6 packet. We have to check the >> packet type too. And if it's not the one we bound to, drop it. >> >> That's what the code snippet I outlined is trying to do. >> >> +-DLS >> > > I beleive I've groked what's going on in vxlan_udp_encap_recv and > vxlan_rcv. There are actually two unrelated problems: > > 1) When the vxlan is configured with IPv4 group it crashes when it > starts to receive IPv6 IGMP packets encapsulated into IPv4 vxlan > packets. This happens because when ipv6_rcv handles the inner packet, > the skb->dst still refernces outer IPv4 info. The very old vxlan code > had skb_dst_drop call in vxlan_udp_encap_recv, which was removed when > vxlan was refactored to use iptunnel_pull_header (commit > 7ce04758279514ca1d8ebfe322508a4a430fe2c8: "vxlan: Restructure vxlan > receive"). The iptunnel_pull_header called skb_dst_drop until recent > commit 10ddceb22bab11dab10ba645c7df2e4a8e7a5db5 ("ip_tunnel:multicast > process cause panic due to skb->_skb_refdst NULL pointer"). > The simplest fix, I think, would be to restore call to skb_dst_drop in > vxlan_udp_encap_recv. > iptunnel_pull() is used in multiple tunnel implementation, therefore we need drop dst in that function. I send out fix : http://marc.info/?l=linux-netdev&m=139563761515707 -- 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