Re: tcp collapse+splice bug still present in -stable

From: David Miller
Date: Sat Sep 11 2010 - 23:32:27 EST


From: Willy Tarreau <w@xxxxxx>
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@xxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxx>
> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
>
> 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;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/