diff --git a/kernel.spec b/kernel.spec index 2a1e32ac1..17fc9033d 100644 --- a/kernel.spec +++ b/kernel.spec @@ -627,6 +627,9 @@ Patch817: 0017-drm-i915-Remove-wm_config-from-dev_priv-intel_atomic.patch #Workaround for glibc update Patch835: 0001-Work-around-for-addition-of-metag-def-but-not-reloca.patch +#CVE-2016-5389 CVE-2016-5969 rhbz 1354708 1355615 +Patch836: tcp-make-challenge-acks-less-predictable.patch + # END OF PATCH DEFINITIONS %endif @@ -2152,6 +2155,9 @@ fi # # %changelog +* Tue Jul 12 2016 Josh Boyer +- CVE-2016-5389 CVE-2016-5969 tcp challenge ack info leak (rhbz 1354708 1355615) + * Mon Jul 11 2016 Justin M. Forbes - 4.7.0-0.rc7.git0.1 - Disable debugging options. - linux v4.7-rc7 diff --git a/tcp-make-challenge-acks-less-predictable.patch b/tcp-make-challenge-acks-less-predictable.patch new file mode 100644 index 000000000..6837cff0b --- /dev/null +++ b/tcp-make-challenge-acks-less-predictable.patch @@ -0,0 +1,81 @@ +From 0af29b4f03b40fe0980c31d18e352f2ef19ec703 Mon Sep 17 00:00:00 2001 +From: Eric Dumazet +Date: Sun, 10 Jul 2016 10:04:02 +0200 +Subject: [PATCH] tcp: make challenge acks less predictable + +Yue Cao claims that current host rate limiting of challenge ACKS +(RFC 5961) could leak enough information to allow a patient attacker +to hijack TCP sessions. He will soon provide details in an academic +paper. + +This patch increases the default limit from 100 to 1000, and adds +some randomization so that the attacker can no longer hijack +sessions without spending a considerable amount of probes. + +Based on initial analysis and patch from Linus. + +Note that we also have per socket rate limiting, so it is tempting +to remove the host limit in the future. + +v2: randomize the count of challenge acks per second, not the period. + +Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2") +Reported-by: Yue Cao +Signed-off-by: Eric Dumazet +Suggested-by: Linus Torvalds +Cc: Yuchung Cheng +Cc: Neal Cardwell +Acked-by: Neal Cardwell +Acked-by: Yuchung Cheng +Signed-off-by: David S. Miller +--- + net/ipv4/tcp_input.c | 15 ++++++++++----- + 1 file changed, 10 insertions(+), 5 deletions(-) + +diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c +index d6c8f4cd0800..91868bb17818 100644 +--- a/net/ipv4/tcp_input.c ++++ b/net/ipv4/tcp_input.c +@@ -87,7 +87,7 @@ int sysctl_tcp_adv_win_scale __read_mostly = 1; + EXPORT_SYMBOL(sysctl_tcp_adv_win_scale); + + /* rfc5961 challenge ack rate limiting */ +-int sysctl_tcp_challenge_ack_limit = 100; ++int sysctl_tcp_challenge_ack_limit = 1000; + + int sysctl_tcp_stdurg __read_mostly; + int sysctl_tcp_rfc1337 __read_mostly; +@@ -3458,7 +3458,7 @@ static void tcp_send_challenge_ack(struct sock *sk, const struct sk_buff *skb) + static u32 challenge_timestamp; + static unsigned int challenge_count; + struct tcp_sock *tp = tcp_sk(sk); +- u32 now; ++ u32 count, now; + + /* First check our per-socket dupack rate limit. */ + if (tcp_oow_rate_limited(sock_net(sk), skb, +@@ -3466,13 +3466,18 @@ static void tcp_send_challenge_ack(struct sock *sk, const struct sk_buff *skb) + &tp->last_oow_ack_time)) + return; + +- /* Then check the check host-wide RFC 5961 rate limit. */ ++ /* Then check host-wide RFC 5961 rate limit. */ + now = jiffies / HZ; + if (now != challenge_timestamp) { ++ u32 half = (sysctl_tcp_challenge_ack_limit + 1) >> 1; ++ + challenge_timestamp = now; +- challenge_count = 0; ++ WRITE_ONCE(challenge_count, half + ++ prandom_u32_max(sysctl_tcp_challenge_ack_limit)); + } +- if (++challenge_count <= sysctl_tcp_challenge_ack_limit) { ++ count = READ_ONCE(challenge_count); ++ if (count > 0) { ++ WRITE_ONCE(challenge_count, count - 1); + NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPCHALLENGEACK); + tcp_send_ack(sk); + } +-- +2.5.5 +