* tcp collapse+splice bug still present in -stable
@ 2010-09-11 5:42 Willy Tarreau
2010-09-12 3:32 ` David Miller
0 siblings, 1 reply; 2+ messages in thread
From: Willy Tarreau @ 2010-09-11 5:42 UTC (permalink / raw)
To: David Miller, Greg KH; +Cc: netdev, linux-kernel, stable
David, Greg,
one of our customers was encountering frequent kernel panics up to
2.6.32.21 that were always related to splicing and tcp_collapse().
I found the precise BUG_ON() line but I've not forgotten it, something
about ->seq not being OK.
I found the following fix in 2.6.35 which looked to be related to the
same issue, and we could verify that it definitely solves it. Could we
please have it in other stable versions ?
Thanks in advance,
Willy
--
>From baff42ab1494528907bf4d5870359e31711746ae Mon Sep 17 00:00:00 2001
From: Steven J. Magnani <steve@digidescorp.com>
Date: Tue, 30 Mar 2010 13:56:01 -0700
Subject: [PATCH] net: Fix oops from tcp_collapse() when using splice()
tcp_read_sock() can have a eat skbs without immediately advancing copied_seq.
This can cause a panic in tcp_collapse() if it is called as a result
of the recv_actor dropping the socket lock.
A userspace program that splices data from a socket to either another
socket or to a file can trigger this bug.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 6afb6d8..2c75f89 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1368,6 +1368,7 @@ int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
sk_eat_skb(sk, skb, 0);
if (!desc->count)
break;
+ tp->copied_seq = seq;
}
tp->copied_seq = seq;
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: tcp collapse+splice bug still present in -stable
2010-09-11 5:42 tcp collapse+splice bug still present in -stable Willy Tarreau
@ 2010-09-12 3:32 ` David Miller
0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 2010-09-12 3:32 UTC (permalink / raw)
To: w; +Cc: greg, netdev, linux-kernel, stable
From: Willy Tarreau <w@1wt.eu>
Date: Sat, 11 Sep 2010 07:42:55 +0200
> David, Greg,
>
> one of our customers was encountering frequent kernel panics up to
> 2.6.32.21 that were always related to splicing and tcp_collapse().
> I found the precise BUG_ON() line but I've not forgotten it, something
> about ->seq not being OK.
>
> I found the following fix in 2.6.35 which looked to be related to the
> same issue, and we could verify that it definitely solves it. Could we
> please have it in other stable versions ?
I'll make sure I send this to Greg in my next -stable
networking batch, thanks!
> --
>>From baff42ab1494528907bf4d5870359e31711746ae Mon Sep 17 00:00:00 2001
> From: Steven J. Magnani <steve@digidescorp.com>
> Date: Tue, 30 Mar 2010 13:56:01 -0700
> Subject: [PATCH] net: Fix oops from tcp_collapse() when using splice()
>
> tcp_read_sock() can have a eat skbs without immediately advancing copied_seq.
> This can cause a panic in tcp_collapse() if it is called as a result
> of the recv_actor dropping the socket lock.
>
> A userspace program that splices data from a socket to either another
> socket or to a file can trigger this bug.
>
> Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
> index 6afb6d8..2c75f89 100644
> --- a/net/ipv4/tcp.c
> +++ b/net/ipv4/tcp.c
> @@ -1368,6 +1368,7 @@ int tcp_read_sock(struct sock *sk, read_descriptor_t *desc,
> sk_eat_skb(sk, skb, 0);
> if (!desc->count)
> break;
> + tp->copied_seq = seq;
> }
> tp->copied_seq = seq;
>
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-09-12 3:32 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-11 5:42 tcp collapse+splice bug still present in -stable Willy Tarreau
2010-09-12 3:32 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).