From owner-freebsd-net@FreeBSD.ORG Sun Jul 3 00:48:57 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82900106566C; Sun, 3 Jul 2011 00:48:57 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C55218FC13; Sun, 3 Jul 2011 00:48:56 +0000 (UTC) Received: by vws18 with SMTP id 18so4185418vws.13 for ; Sat, 02 Jul 2011 17:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vV7eo2/xGIPgyWbzyLydVpZlEYPmxLpM5Mvyxm65X4M=; b=ZiWCNr1Asz65bdAFfMUKEPlTlQTZqw3WtHpArAEZTBHr19TZzQHHXqnFTyL7hTD9y4 Yfelc/FeSYP0ZzqBtGLwhyWxoUDWzHd1YUxNcBHuYlnKUCMZVyxJEkSntaezDV/Naz73 Sg+Gyy9pnbGH9Gfig4I22kJYGe9XG1xrEOpUU= MIME-Version: 1.0 Received: by 10.52.166.70 with SMTP id ze6mr2981165vdb.133.1309654136120; Sat, 02 Jul 2011 17:48:56 -0700 (PDT) Received: by 10.52.114.99 with HTTP; Sat, 2 Jul 2011 17:48:56 -0700 (PDT) In-Reply-To: <4E0F8C95.50507@freebsd.org> References: <4E0F8C95.50507@freebsd.org> Date: Sat, 2 Jul 2011 17:48:56 -0700 Message-ID: From: Jack Vogel To: Colin Percival Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jack F Vogel , freebsd-net@freebsd.org Subject: Re: integer overflow in TCP LRO X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2011 00:48:57 -0000 Looks good to me, good work! Jack On Sat, Jul 2, 2011 at 2:24 PM, Colin Percival wrote: > Hi all, > > In tcp_lro_rx it's possible for lro->len to exceed 65536, resulting in an > integer overflow and 65536 bytes of TCP "packet loss" when tcp_lro_flush > stuffs lro->len back into an IP header. > > It's clear that an attempt was made to avoid overflow > 339: /* flush packet if required */ > 340: device_mtu = cntl->ifp->if_mtu; > 341: if (lro->len > (65535 - device_mtu)) { > but this doesn't work because incoming "packets" can be larger than > device_mtu bytes if LRO is turned on. > > I've attached a patch which fixes this and improves Linux->FreeBSD network > performance on EC2 cluster compute nodes from 13 Mbps to 4100 Mbps... any > objections to me committing this? > > -- > Colin Percival > Security Officer, FreeBSD | freebsd.org | The power to serve > Founder / author, Tarsnap | tarsnap.com | Online backups for the truly > paranoid >