linux-toradex.git/net/ipv6, branch v2.6.32.50

ipv6: udp: fix the wrong headroom check

2011-11-26T17:10:36+00:00

commit a9cf73ea7ff78f52662c8658d93c226effbbedde upstream.

At this point, skb->data points to skb_transport_header.
So, headroom check is wrong.

For some case:bridge(UFO is on) + eth device(UFO is off),
there is no enough headroom for IPv6 frag head.
But headroom check is always false.

This will bring about data be moved to there prior to skb->head,
when adding IPv6 frag header to skb.

Signed-off-by: Shan Wei 
Acked-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: Add GSO support on forwarding path

2011-11-07T20:31:51+00:00

commit 0aa68271510ae2b221d4b60892103837be63afe4 upstream.

Currently we disallow GSO packets on the IPv6 forward path.
This patch fixes this.

Note that I discovered that our existing GSO MTU checks (e.g.,
IPv4 forwarding) are buggy in that they skip the check altogether,
when they really should be checking gso_size + header instead.

I have also been lazy here in that I haven't bothered to segment
the GSO packet by hand before generating an ICMP message.  Someone
should add that to be 100% correct.

Reported-by: Ralf Baechle 
Signed-off-by: Herbert Xu 
Signed-off-by: David S. Miller 
Signed-off-by: Apollon Oikonomopoulos 
Signed-off-by: Faidon Liambotis 
Signed-off-by: Greg Kroah-Hartman

Fix broken backport for IPv6 tunnels

2011-11-07T20:31:50+00:00

Fix broken backport for IPv6 tunnels in 2.6.32-longterm kernels.

upstream commit d5aa407f59f5b83d2c50ec88f5bf56d40f1f8978 ("tunnels: fix
netns vs proto registration ordering") , which was included in
2.6.32.44-longterm, was not backported correctly, and results in a NULL
pointer dereference in ip6_tunnel.c for longterm kernels >=2.6.32.44

Use [un]register_pernet_gen_device() instead of
[un]register_pernet_device() to fix it.

Signed-off-by: Stratos Psomadakis 
Cc: Wolfgang Walter 
Cc: Tim Gardner 
Cc: Andy Whitcroft 
Signed-off-by: Greg Kroah-Hartman

net: Compute protocol sequence numbers and fragment IDs using MD5.

2011-08-16T01:57:20+00:00

Computers have become a lot faster since we compromised on the
partial MD4 hash which we use currently for performance reasons.

MD5 is a much safer choice, and is inline with both RFC1948 and
other ISS generators (OpenBSD, Solaris, etc.)

Furthermore, only having 24-bits of the sequence number be truly
unpredictable is a very serious limitation.  So the periodic
regeneration and 8-bit counter have been removed.  We compute and
use a full 32-bit sequence number.

For ipv6, DCCP was found to use a 32-bit truncated initial sequence
number (it needs 43-bits) and that is fixed here as well.

Reported-by: Dan Kaminsky 
Tested-by: Willy Tarreau 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tunnels: fix netns vs proto registration ordering

2011-08-08T17:23:18+00:00

commit d5aa407f59f5b83d2c50ec88f5bf56d40f1f8978 upstream.

Same stuff as in ip_gre patch: receive hook can be called before netns
setup is done, oopsing in net_generic().

Signed-off-by: Alexey Dobriyan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netns xfrm: fixup xfrm6_tunnel error propagation

2011-08-08T17:23:17+00:00

commit e924960dacdf85d118a98c7262edf2f99c3015cf upstream.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet

2011-07-13T03:29:27+00:00

[ Upstream commit 9cfaa8def1c795a512bc04f2aec333b03724ca2e ]

Consider this scenario: When the size of the first received udp packet
is bigger than the receive buffer, MSG_TRUNC bit is set in msg->msg_flags.
However, if checksum error happens and this is a blocking socket, it will
goto try_again loop to receive the next packet.  But if the size of the
next udp packet is smaller than receive buffer, MSG_TRUNC flag should not
be set, but because MSG_TRUNC bit is not cleared in msg->msg_flags before
receive the next packet, MSG_TRUNC is still set, which is wrong.

Fix this problem by clearing MSG_TRUNC flag when starting over for a
new packet.

Signed-off-by: Xufeng Zhang 
Signed-off-by: Paul Gortmaker 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6/udp: Use the correct variable to determine non-blocking condition

2011-07-13T03:29:27+00:00

[ Upstream commit 32c90254ed4a0c698caa0794ebb4de63fcc69631 ]

udpv6_recvmsg() function is not using the correct variable to determine
whether or not the socket is in non-blocking operation, this will lead
to unexpected behavior when a UDP checksum error occurs.

Consider a non-blocking udp receive scenario: when udpv6_recvmsg() is
called by sock_common_recvmsg(), MSG_DONTWAIT bit of flags variable in
udpv6_recvmsg() is cleared by "flags & ~MSG_DONTWAIT" in this call:

    err = sk->sk_prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT,
                   flags & ~MSG_DONTWAIT, &addr_len);

i.e. with udpv6_recvmsg() getting these values:

	int noblock = flags & MSG_DONTWAIT
	int flags = flags & ~MSG_DONTWAIT

So, when udp checksum error occurs, the execution will go to
csum_copy_err, and then the problem happens:

    csum_copy_err:
            ...............
            if (flags & MSG_DONTWAIT)
                    return -EAGAIN;
            goto try_again;
            ...............

But it will always go to try_again as MSG_DONTWAIT has been cleared
from flags at call time -- only noblock contains the original value
of MSG_DONTWAIT, so the test should be:

            if (noblock)
                    return -EAGAIN;

This is also consistent with what the ipv4/udp code does.

Signed-off-by: Xufeng Zhang 
Signed-off-by: Paul Gortmaker 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

netfilter: IPv6: initialize TOS field in REJECT target module

2011-06-23T22:24:09+00:00

commit 4319cc0cf5bb894b7368008cdf6dd20eb8868018 upstream.

The IPv6 header is not zeroed out in alloc_skb so we must initialize
it properly unless we want to see IPv6 packets with random TOS fields
floating around. The current implementation resets the flow label
but this could be changed if deemed necessary.

We stumbled upon this issue when trying to apply a mangle rule to
the RST packet generated by the REJECT target module.

Signed-off-by: Fernando Luis Vazquez Cao 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_conntrack_reasm: properly handle packets fragmented into a single fragment

2011-06-23T22:24:05+00:00

commit 9e2dcf72023d1447f09c47d77c99b0c49659e5ce upstream.

When an ICMPV6_PKT_TOOBIG message is received with a MTU below 1280,
all further packets include a fragment header.

Unlike regular defragmentation, conntrack also needs to "reassemble"
those fragments in order to obtain a packet without the fragment
header for connection tracking. Currently nf_conntrack_reasm checks
whether a fragment has either IP6_MF set or an offset != 0, which
makes it ignore those fragments.

Remove the invalid check and make reassembly handle fragment queues
containing only a single fragment.

Reported-and-tested-by: Ulrich Weber 
Signed-off-by: Patrick McHardy 
Signed-off-by: Greg Kroah-Hartman