kernel/git/stable/linux.git/net/dccp, branch linux-2.6.32.y

dccp: catch failed request_module call in dccp_probe init

2015-09-18T11:52:19+00:00

commit 965cdea825693c821d200e38fac9402cde6dce6a upstream. Check the return value of request_module during dccp_probe initialisation, bail out if that call fails. Signed-off-by: Gerrit Renker Signed-off-by: Wang Weidong Signed-off-by: David S. Miller Signed-off-by: Willy Tarreau

dccp: Fix compile warning in probe code.

2015-09-18T11:52:18+00:00

commit d984e6197ecd2babc1537f42dc1e676133005cda upstream. Commit 1386be55e32a3c5d8ef4a2b243c530a7b664c02c ("dccp: fix auto-loading of dccp(_probe)") fixed a bug but created a new compiler warning: net/dccp/probe.c: In function âdccpprobe_initâ: net/dccp/probe.c:166:2: warning: the omitted middle operand in ?: will always be âtrueâ, suggest explicit middle operand [-Wparentheses] try_then_request_module() is built for situations where the "existence" test is some lookup function that returns a non-NULL object on success, and with a reference count of some kind held. Here we're looking for a success return of zero from the jprobe registry. Instead of fighting the way try_then_request_module() works, simply open code what we want to happen in a local helper function. Signed-off-by: David S. Miller Signed-off-by: Willy Tarreau

dccp: fix auto-loading of dccp(_probe)

2015-09-18T11:52:18+00:00

commit 1386be55e32a3c5d8ef4a2b243c530a7b664c02c upstream. This fixes commit (38ff3e6bb987ec583268da8eb22628293095d43b) ("dccp_probe: Fix module load dependencies between dccp and dccp_probe", from 15 Jan). It fixes the construction of the first argument of try_then_request_module(), where only valid return codes from the first argument should be returned. What we do now is assign the result of register_jprobe() to ret, without the side effect of the comparison. Acked-by: Gerrit Renker Signed-off-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Willy Tarreau

inet: add RCU protection to inet->opt

2013-06-10T09:43:31+00:00

commit f6d8bd051c391c1c0458a30b2a7abcd939329259 upstream. We lack proper synchronization to manipulate inet->opt ip_options Problem is ip_make_skb() calls ip_setup_cork() and ip_setup_cork() possibly makes a copy of ipc->opt (struct ip_options), without any protection against another thread manipulating inet->opt. Another thread can change inet->opt pointer and free old one under us. Use RCU to protect inet->opt (changed to inet->inet_opt). Instead of handling atomic refcounts, just copy ip_options when necessary, to avoid cache line dirtying. We cant insert an rcu_head in struct ip_options since its included in skb->cb[], so this patch is large because I had to introduce a new ip_options_rcu structure. Signed-off-by: Eric Dumazet Cc: Herbert Xu Signed-off-by: David S. Miller [dannf/bwh: backported to Debian's 2.6.32] Signed-off-by: Ben Hutchings Signed-off-by: Willy Tarreau

dccp: check ccid before dereferencing

2012-10-07T21:40:59+00:00

commit 276bdb82dedb290511467a5a4fdbe9f0b52dce6f upstream. ccid_hc_rx_getsockopt() and ccid_hc_tx_getsockopt() might be called with a NULL ccid pointer leading to a NULL pointer dereference. This could lead to a privilege escalation if the attacker is able to map page 0 and prepare it with a fake ccid_ops pointer. Signed-off-by: Mathias Krause Cc: Gerrit Renker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Willy Tarreau

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

dccp: handle invalid feature options length

2011-05-23T18:20:15+00:00

commit a294865978b701e4d0d90135672749531b9a900d upstream. A length of zero (after subtracting two for the type and len fields) for the DCCPO_{CHANGE,CONFIRM}_{L,R} options will cause an underflow due to the subtraction. The subsequent code may read past the end of the options value buffer when parsing. I'm unsure of what the consequences of this might be, but it's probably not good. Signed-off-by: Dan Rosenberg Acked-by: Gerrit Renker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

dccp: fix oops on Reset after close

2011-03-07T23:17:57+00:00

commit 720dc34bbbe9493c7bd48b2243058b4e447a929d upstream. This fixes a bug in the order of dccp_rcv_state_process() that still permitted reception even after closing the socket. A Reset after close thus causes a NULL pointer dereference by not preventing operations on an already torn-down socket. dccp_v4_do_rcv() | | state other than OPEN v dccp_rcv_state_process() | | DCCP_PKT_RESET v dccp_rcv_reset() | v dccp_time_wait() WARNING: at net/ipv4/inet_timewait_sock.c:141 __inet_twsk_hashdance+0x48/0x128() Modules linked in: arc4 ecb carl9170 rt2870sta(C) mac80211 r8712u(C) crc_ccitt ah [] (unwind_backtrace+0x0/0xec) from [] (warn_slowpath_common) [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_n) [] (warn_slowpath_null+0x1c/0x24) from [] (__inet_twsk_hashd) [] (__inet_twsk_hashdance+0x48/0x128) from [] (dccp_time_wai) [] (dccp_time_wait+0x40/0xc8) from [] (dccp_rcv_state_proces) [] (dccp_rcv_state_process+0x120/0x538) from [] (dccp_v4_do_) [] (dccp_v4_do_rcv+0x11c/0x14c) from [] (release_sock+0xac/0) [] (release_sock+0xac/0x110) from [] (dccp_close+0x28c/0x380) [] (dccp_close+0x28c/0x380) from [] (inet_release+0x64/0x70) The fix is by testing the socket state first. Receiving a packet in Closed state now also produces the required "No connection" Reset reply of RFC 4340, 8.3.1. Reported-and-tested-by: Johan Hovold Signed-off-by: Gerrit Renker Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

dccp_probe: Fix module load dependencies between dccp and dccp_probe

2010-05-12T21:57:11+00:00

commit 38ff3e6bb987ec583268da8eb22628293095d43b upstream. This was just recently reported to me. When built as modules, the dccp_probe module has a silent dependency on the dccp module. This stems from the fact that the module_init routine of dccp_probe registers a jprobe on the dccp_sendmsg symbol. Since the symbol is only referenced as a text string (the .symbol_name field in the jprobe struct) rather than the address of the symbol itself, depmod never picks this dependency up, and so if you load the dccp_probe module without the dccp module loaded, the register_jprobe call fails with an -EINVAL, and the whole module load fails. The fix is pretty easy, we can just wrap the register_jprobe call in a try_then_request_module call, which forces the dependency to get satisfied prior to the probe registration. Signed-off-by: Neil Horman Acked-by: Arnaldo Carvalho de Melo Signed-off-by: David S. Miller Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman

net: Make setsockopt() optlen be unsigned.

2009-09-30T23:12:20+00:00

This provides safety against negative optlen at the type level instead of depending upon (sometimes non-trivial) checks against this sprinkled all over the the place, in each and every implementation. Based upon work done by Arjan van de Ven and feedback from Linus Torvalds. Signed-off-by: David S. Miller