summaryrefslogtreecommitdiffstats
path: root/recipes-kernel/linux/linux-cavium/CVE-2017-6214.patch
diff options
context:
space:
mode:
Diffstat (limited to 'recipes-kernel/linux/linux-cavium/CVE-2017-6214.patch')
-rw-r--r--recipes-kernel/linux/linux-cavium/CVE-2017-6214.patch52
1 files changed, 0 insertions, 52 deletions
diff --git a/recipes-kernel/linux/linux-cavium/CVE-2017-6214.patch b/recipes-kernel/linux/linux-cavium/CVE-2017-6214.patch
deleted file mode 100644
index 640ed5c..0000000
--- a/recipes-kernel/linux/linux-cavium/CVE-2017-6214.patch
+++ /dev/null
@@ -1,52 +0,0 @@
1From 0f895f51a831d73ce24158534784aba5b2a72a9e Mon Sep 17 00:00:00 2001
2From: Eric Dumazet <edumazet@google.com>
3Date: Fri, 3 Feb 2017 14:59:38 -0800
4Subject: [PATCH] tcp: avoid infinite loop in tcp_splice_read()
5
6[ Upstream commit ccf7abb93af09ad0868ae9033d1ca8108bdaec82 ]
7
8Splicing from TCP socket is vulnerable when a packet with URG flag is
9received and stored into receive queue.
10
11__tcp_splice_read() returns 0, and sk_wait_data() immediately
12returns since there is the problematic skb in queue.
13
14This is a nice way to burn cpu (aka infinite loop) and trigger
15soft lockups.
16
17Again, this gem was found by syzkaller tool.
18
19CVE: CVE-2017-6214
20Upstream-Status: Backport [from kernel.org longterm 4.9.52]
21
22Fixes: 9c55e01c0cc8 ("[TCP]: Splice receive support.")
23Signed-off-by: Eric Dumazet <edumazet@google.com>
24Reported-by: Dmitry Vyukov <dvyukov@google.com>
25Cc: Willy Tarreau <w@1wt.eu>
26Signed-off-by: David S. Miller <davem@davemloft.net>
27Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
28Signed-off-by: Sona Sarmadi <sona.sarmadi@enea.com>
29---
30 net/ipv4/tcp.c | 6 ++++++
31 1 file changed, 6 insertions(+)
32
33diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
34index 814af89..6a90a0e 100644
35--- a/net/ipv4/tcp.c
36+++ b/net/ipv4/tcp.c
37@@ -772,6 +772,12 @@ ssize_t tcp_splice_read(struct socket *sock, loff_t *ppos,
38 ret = -EAGAIN;
39 break;
40 }
41+ /* if __tcp_splice_read() got nothing while we have
42+ * an skb in receive queue, we do not want to loop.
43+ * This might happen with URG data.
44+ */
45+ if (!skb_queue_empty(&sk->sk_receive_queue))
46+ break;
47 sk_wait_data(sk, &timeo, NULL);
48 if (signal_pending(current)) {
49 ret = sock_intr_errno(timeo);
50--
511.9.1
52