linux/net/ipv6, branch v3.8.9

ipv6: don't accept node local multicast traffic from the wire

2013-04-05T16:26:19Z

[ Upstream commit 1c4a154e5253687c51123956dfcee9e9dfa8542d ] Erik Hugne's errata proposal (Errata ID: 3480) to RFC4291 has been verified: http://www.rfc-editor.org/errata_search.php?eid=3480 We have to check for pkt_type and loopback flag because either the packets are allowed to travel over the loopback interface (in which case pkt_type is PACKET_HOST and IFF_LOOPBACK flag is set) or they travel over a non-loopback interface back to us (in which case PACKET_TYPE is PACKET_LOOPBACK and IFF_LOOPBACK flag is not set). Signed-off-by: Hannes Frederic Sowa Cc: Erik Hugne Cc: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ipv6: don't accept multicast traffic with scope 0

2013-04-05T16:26:19Z

[ Upstream commit 20314092c1b41894d8c181bf9aa6f022be2416aa ] v2: a) moved before multicast source address check b) changed comment to netdev style Acked-by: YOSHIFUJI Hideaki Cc: Erik Hugne Cc: YOSHIFUJI Hideaki Signed-off-by: Hannes Frederic Sowa Acked-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ipv6: fix bad free of addrconf_init_net

2013-04-05T16:26:18Z

[ Upstream commit a79ca223e029aa4f09abb337accf1812c900a800 ] Signed-off-by: Hong Zhiguo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

inet: limit length of fragment queue hash table bucket lists

2013-03-28T19:17:23Z

[ Upstream commit 5a3da1fe9561828d0ca7eca664b16ec2b9bf0055 ] This patch introduces a constant limit of the fragment queue hash table bucket list lengths. Currently the limit 128 is choosen somewhat arbitrary and just ensures that we can fill up the fragment cache with empty packets up to the default ip_frag_high_thresh limits. It should just protect from list iteration eating considerable amounts of cpu. If we reach the maximum length in one hash bucket a warning is printed. This is implemented on the caller side of inet_frag_find to distinguish between the different users of inet_fragment.c. I dropped the out of memory warning in the ipv4 fragment lookup path, because we already get a warning by the slab allocator. Cc: Eric Dumazet Cc: Jesper Dangaard Brouer Signed-off-by: Hannes Frederic Sowa Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

tcp: dont handle MTU reduction on LISTEN socket

2013-03-28T19:17:22Z

[ Upstream commit 0d4f0608619de59fd8169dd8e72aadc28d80e715 ] When an ICMP ICMP_FRAG_NEEDED (or ICMPV6_PKT_TOOBIG) message finds a LISTEN socket, and this socket is currently owned by the user, we set TCP_MTU_REDUCED_DEFERRED flag in listener tsq_flags. This is bad because if we clone the parent before it had a chance to clear the flag, the child inherits the tsq_flags value, and next tcp_release_cb() on the child will decrement sk_refcnt. Result is that we might free a live TCP socket, as reported by Dormando. IPv4: Attempt to release TCP socket in state 1 Fix this issue by testing sk_state against TCP_LISTEN early, so that we set TCP_MTU_REDUCED_DEFERRED on appropriate sockets (not a LISTEN one) This bug was introduced in commit 563d34d05786 (tcp: dont drop MTU reduction indications) Reported-by: dormando Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ipv6: stop multicast forwarding to process interface scoped addresses

2013-03-20T20:10:58Z

[ Upstream commit ddf64354af4a702ee0b85d0a285ba74c7278a460 ] v2: a) used struct ipv6_addr_props v3: a) reverted changes for ipv6_addr_props v4: a) do not use __ipv6_addr_needs_scope_id Cc: YOSHIFUJI Hideaki Signed-off-by: Hannes Frederic Sowa Acked-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: ipv6: Don't purge default router if accept_ra=2

2013-03-20T20:10:57Z

[ Upstream commit 3e8b0ac3e41e3c882222a5522d5df7212438ab51 ] Setting net.ipv6.conf..accept_ra=2 causes the kernel to accept RAs even when forwarding is enabled. However, enabling forwarding purges all default routes on the system, breaking connectivity until the next RA is received. Fix this by not purging default routes on interfaces that have accept_ra=2. Signed-off-by: Lorenzo Colitti Acked-by: YOSHIFUJI Hideaki Acked-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

ipv6: fix race condition regarding dst->expires and dst->from.

2013-02-28T13:38:40Z

[ Upstream commit ecd9883724b78cc72ed92c98bcb1a46c764fff21 ] Eric Dumazet wrote: | Some strange crashes happen in rt6_check_expired(), with access | to random addresses. | | At first glance, it looks like the RTF_EXPIRES and | stuff added in commit 1716a96101c49186b | (ipv6: fix problem with expired dst cache) | are racy : same dst could be manipulated at the same time | on different cpus. | | At some point, our stack believes rt->dst.from contains a dst pointer, | while its really a jiffie value (as rt->dst.expires shares the same area | of memory) | | rt6_update_expires() should be fixed, or am I missing something ? | | CC Neil because of https://bugzilla.redhat.com/show_bug.cgi?id=892060 Because we do not have any locks for dst_entry, we cannot change essential structure in the entry; e.g., we cannot change reference to other entity. To fix this issue, split 'from' and 'expires' field in dst_entry out of union. Once it is 'from' is assigned in the constructor, keep the reference until the very last stage of the life time of the object. Of course, it is unsafe to change 'from', so make rt6_set_from simple just for fresh entries. Reported-by: Eric Dumazet Reported-by: Neil Horman CC: Gao Feng Signed-off-by: YOSHIFUJI Hideaki Reviewed-by: Eric Dumazet Reported-by: Steinar H. Gunderson Reviewed-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

xfrm: release neighbor upon dst destruction

2013-02-28T13:38:40Z

[ Upstream commit 18cf0d0784b4a634472ed24d0d7ca1c721d93e90 ] Neighbor is cloned in xfrm6_fill_dst but seems to never be released. Neighbor entry should be released when XFRM6 dst entry is destroyed in xfrm6_dst_destroy, otherwise references may be kept forever on the device pointed by the neighbor entry. I may not have understood all the subtleties of XFRM & dst so I would be happy to receive comments on this patch. Signed-off-by: Romain Kuntz Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

Merge branch 'master' of git://1984.lsi.us.es/nf

2013-02-11T01:44:08Z

Pablo Neira Ayuso says: ==================== The following patchset contains Netfilter/IPVS fixes for 3.8-rc7, they are: * Fix oops in IPVS state-sync due to releasing a random memory area due to unitialized pointer, from Dan Carpenter. * Fix SCTP flow establishment due to bad checksumming mangling in IPVS, from Daniel Borkmann. * Three fixes for the recently added IPv6 NPT, all from YOSHIFUJI Hideaki, with an amendment collapsed into those patches from Ulrich Weber. They fiix adjustment calculation, fix prefix mangling and ensure LSB of prefixes are zeroes (as required by RFC). Specifically, it took me a while to validate the 1's complement arithmetics/ checksumming approach in the IPv6 NPT code. ==================== Signed-off-by: David S. Miller