kernel/linux.git/include/net, branch v3.0.22

net: fix NULL dereferences in check_peer_redir()

2012-02-13T19:06:13+00:00

[ Upstream commit d3aaeb38c40e5a6c08dd31a1b64da65c4352be36, along with dependent backports of commits: 69cce1d1404968f78b177a0314f5822d5afdbbfb 9de79c127cccecb11ae6a21ab1499e87aa222880 218fa90f072e4aeff9003d57e390857f4f35513e 580da35a31f91a594f3090b7a2c39b85cb051a12 f7e57044eeb1841847c24aa06766c8290c202583 e049f28883126c689cf95859480d9ee4ab23b7fa ] Gergely Kalman reported crashes in check_peer_redir(). It appears commit f39925dbde778 (ipv4: Cache learned redirect information in inetpeer.) added a race, leading to possible NULL ptr dereference. Since we can now change dst neighbour, we should make sure a reader can safely use a neighbour. Add RCU protection to dst neighbour, and make sure check_peer_redir() can be called safely by different cpus in parallel. As neighbours are already freed after one RCU grace period, this patch should not add typical RCU penalty (cache cold effects) Many thanks to Gergely for providing a pretty report pointing to the bug. Reported-by: Gergely Kalman Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

netns: Fail conspicously if someone uses net_generic at an inappropriate time.

2012-02-03T17:19:03+00:00

[ Upstream commit 5ee4433efe99b9f39f6eff5052a177bbcfe72cea ] By definition net_generic should never be called when it can return NULL. Fail conspicously with a BUG_ON to make it clear when people mess up that a NULL return should never happen. Recently there was a bug in the CAIF subsystem where it was registered with register_pernet_device instead of register_pernet_subsys. It was erroneously concluded that net_generic could validly return NULL and that net_assign_generic was buggy (when it was just inefficient). Hopefully this BUG_ON will prevent people to coming to similar erroneous conclusions in the futrue. Signed-off-by: Eric W. Biederman Tested-by: Sasha Levin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

sctp: fix incorrect overflow check on autoclose

2012-01-06T22:14:08+00:00

[ Upstream commit 2692ba61a82203404abd7dd2a027bda962861f74 ] Commit 8ffd3208 voids the previous patches f6778aab and 810c0719 for limiting the autoclose value. If userspace passes in -1 on 32-bit platform, the overflow check didn't work and autoclose would be set to 0xffffffff. This patch defines a max_autoclose (in seconds) for limiting the value and exposes it through sysctl, with the following intentions. 1) Avoid overflowing autoclose * HZ. 2) Keep the default autoclose bound consistent across 32- and 64-bit platforms (INT_MAX / HZ in this patch). 3) Keep the autoclose value consistent between setsockopt() and getsockopt() calls. Suggested-by: Vlad Yasevich Signed-off-by: Xi Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

net: Handle different key sizes between address families in flow cache

2011-11-11T17:37:17+00:00

commit aa1c366e4febc7f5c2b84958a2dd7cd70e28f9d0 upstream. With the conversion of struct flowi to a union of AF-specific structs, some operations on the flow cache need to account for the exact size of the key. Signed-off-by: David Ward Signed-off-by: David S. Miller Cc: Kim Phillips Signed-off-by: Greg Kroah-Hartman

net: Align AF-specific flowi structs to long

2011-11-11T17:37:17+00:00

commit 728871bc05afc8ff310b17dba3e57a2472792b13 upstream. AF-specific flowi structs are now passed to flow_key_compare, which must also be aligned to a long. Signed-off-by: David Ward Signed-off-by: David S. Miller Cc: Kim Phillips Signed-off-by: Greg Kroah-Hartman

ipv6: fix NULL dereference in udp6_ufo_fragment()

2011-10-16T21:14:54+00:00

This patch fixes the issue caused by ef81bb40bf15f350fe865f31fa42f1082772a576 which is a backport of upstream 87c48fa3b4630905f98268dde838ee43626a060c. The problem does not exist in upstream. We do not check whether route is attached before trying to assign ip identification through route dest which lead NULL pointer dereference. This happens when host bridge transmit a packet from guest. This patch changes ipv6_select_ident() to accept in6_addr as its paramter and fix the issue by using the destination address in ipv6 header when no route is attached. Signed-off-by: Jason Wang Acked-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

fs/9p: Use protocol-defined value for lock/getlock 'type' field.

2011-10-03T18:40:22+00:00

commit 51b8b4fb32271d39fbdd760397406177b2b0fd36 upstream. Signed-off-by: Jim Garlick Signed-off-by: Aneesh Kumar K.V Signed-off-by: Harsh Prateek Bora Signed-off-by: Greg Kroah-Hartman

fs/9p: Add OS dependent open flags in 9p protocol

2011-10-03T18:40:21+00:00

commit f88657ce3f9713a0c62101dffb0e972a979e77b9 upstream. Some of the flags are OS/arch dependent we add a 9p protocol value which maps to asm-generic/fcntl.h values in Linux Based on the original patch from Venkateswararao Jujjuri [extra comments from author as to why this needs to go to stable: Earlier for different operation such as open we used the values of open flag as defined by the OS. But some of these flags such as O_DIRECT are arch dependent. So if we have the 9p client and server running on different architectures, we end up with client sending client architecture value of these open flag and server will try to map these values to what its architecture states. For ex: O_DIRECT on a x86 client maps to #define O_DIRECT 00040000 Where as on sparc server it will maps to #define O_DIRECT 0x100000 Hence we need to map these open flags to OS/arch independent flag values. Getting these changes to an early version of kernel ensures us that we work with different combination of client and server. We should ideally backport this patch to all possible kernel version.] Signed-off-by: Aneesh Kumar K.V Signed-off-by: Harsh Prateek Bora Signed-off-by: Greg Kroah-Hartman

ipv6: make fragment identifications less predictable

2011-08-16T01:31:37+00:00

[ Backport of upstream commit 87c48fa3b4630905f98268dde838ee43626a060c ] Fernando Gont reported current IPv6 fragment identification generation was not secure, because using a very predictable system-wide generator, allowing various attacks. IPv4 uses inetpeer cache to address this problem and to get good performance. We'll use this mechanism when IPv6 inetpeer is stable enough in linux-3.1 For the time being, we use jhash on destination address to provide less predictable identifications. Also remove a spinlock and use cmpxchg() to get better SMP performance. Reported-by: Fernando Gont Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

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

2011-08-16T01:31:35+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