From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Dumazet Subject: Re: [PATCH net 1/2] tcp: Limit number of segments generated by GSO per skb Date: Mon, 30 Jul 2012 19:31:47 +0200 Message-ID: <1343669507.21269.33.camel@edumazet-glaptop> References: <1343668498.2667.5.camel@bwh-desktop.uk.solarflarecom.com> <1343668602.2667.6.camel@bwh-desktop.uk.solarflarecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: David Miller , netdev@vger.kernel.org, linux-net-drivers@solarflare.com To: Ben Hutchings Return-path: Received: from mail-bk0-f46.google.com ([209.85.214.46]:53874 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754347Ab2G3Rbx (ORCPT ); Mon, 30 Jul 2012 13:31:53 -0400 Received: by bkwj10 with SMTP id j10so2935990bkw.19 for ; Mon, 30 Jul 2012 10:31:51 -0700 (PDT) In-Reply-To: <1343668602.2667.6.camel@bwh-desktop.uk.solarflarecom.com> Sender: netdev-owner@vger.kernel.org List-ID: On Mon, 2012-07-30 at 18:16 +0100, Ben Hutchings wrote: > A peer (or local user) may cause TCP to use a nominal MSS of as little > as 88 (actual MSS of 76 with timestamps). Given that we have a > sufficiently prodigious local sender and the peer ACKs quickly enough, > it is nevertheless possible to grow the window for such a connection > to the point that we will try to send just under 64K at once. This > results in a single skb that expands to 861 segments. > > In some drivers with TSO support, such an skb will require hundreds of > DMA descriptors; a substantial fraction of a TX ring or even more than > a full ring. The TX queue selected for the skb may stall and trigger > the TX watchdog repeatedly (since the problem skb will be retried > after the TX reset). This particularly affects sfc, for which the > issue is designated as CVE-2012-3412. However it may be that some > hardware or firmware also fails to handle such an extreme TSO request > correctly. > > Therefore, limit the number of segments per skb to 100. This should > make no difference to behaviour unless the actual MSS is less than > about 700. > > Signed-off-by: Ben Hutchings > --- Hmm, isnt GRO path also vulnerable ? An alternative would be to drop such frames in the ndo_start_xmit(), and cap sk->sk_gso_max_size (since skb are no longer orphaned...) Or you could introduce a new wk->sk_gso_max_segments, that your sfc driver sets to whatever limit ?