Skip to contentSkip to conversation

Patch "tcp: avoid infinite loop in tcp_splice_read()" has been added to the 4.4-stable tree

PATCH [email protected] 1 participant 1 message Feb 15, 2017

Subsystems (3)
lore
Share & tools
lore

[email protected]

author maintainer Applied
#0 lore raw

This is a note to let you know that I've just added the patch titled

tcp: avoid infinite loop in tcp_splice_read()

to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
tcp-avoid-infinite-loop-in-tcp_splice_read.patch
and it can be found in the queue-4.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From foo@baz Tue Feb 14 16:29:59 PST 2017

From: Eric Dumazet <[email protected]>
Date: Fri, 3 Feb 2017 14:59:38 -0800
Subject: tcp: avoid infinite loop in tcp_splice_read()

From: Eric Dumazet <[email protected]>

[ Upstream commit ccf7abb93af09ad0868ae9033d1ca8108bdaec82 ]

Splicing from TCP socket is vulnerable when a packet with URG flag is received and stored into receive queue.

__tcp_splice_read() returns 0, and sk_wait_data() immediately returns since there is the problematic skb in queue.

This is a nice way to burn cpu (aka infinite loop) and trigger soft lockups.

Again, this gem was found by syzkaller tool.

Fixes 9c55e01c0cc8 ("[TCP]: Splice receive support.")
Cc Willy Tarreau <[email protected]>
---
 net/ipv4/tcp.c |    6 ++++++
 1 file changed, 6 insertions(+)
net/ipv4/tcp.c +6 -0
@@ -783,6 +783,12 @@ ssize_t tcp_splice_read(struct socket *s
 				ret = -EAGAIN;
 				break;
 			}
+			/* if __tcp_splice_read() got nothing while we have
+			 * an skb in receive queue, we do not want to loop.
+			 * This might happen with URG data.
+			 */
+			if (!skb_queue_empty(&sk->sk_receive_queue))
+				break;
 			sk_wait_data(sk, &timeo, NULL);
 			if (signal_pending(current)) {
 				ret = sock_intr_errno(timeo);

Patches currently in stable-queue which might be from [email protected] are

queue-4.4/ipv6-pointer-math-error-in-ip6_tnl_parse_tlv_enc_lim.patch queue-4.4/netlabel-out-of-bound-access-in-cipso_v4_validate.patch queue-4.4/packet-round-up-linear-to-header-len.patch queue-4.4/tun-read-vnet_hdr_sz-once.patch queue-4.4/ipv6-fix-ip6_tnl_parse_tlv_enc_lim.patch queue-4.4/l2tp-do-not-use-udp_ioctl.patch queue-4.4/tcp-fix-0-divide-in-__tcp_select_window.patch queue-4.4/can-fix-kernel-panic-at-security_sock_rcv_skb.patch queue-4.4/net-introduce-device-min_header_len.patch queue-4.4/macvtap-read-vnet_hdr_size-once.patch queue-4.4/tcp-avoid-infinite-loop-in-tcp_splice_read.patch queue-4.4/mlx4-invoke-softirqs-after-napi_reschedule.patch queue-4.4/ipv6-tcp-add-a-missing-tcp_v6_restore_cb.patch queue-4.4/ipv4-keep-skb-dst-around-in-presence-of-ip-options.patch queue-4.4/net-use-a-work-queue-to-defer-net_disable_timestamp-work.patch queue-4.4/ip6_gre-fix-ip6gre_err-invalid-reads.patch