From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1949576AbdDYPT3 (ORCPT ); Tue, 25 Apr 2017 11:19:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52328 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1949160AbdDYPMw (ORCPT ); Tue, 25 Apr 2017 11:12:52 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 034953D979 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=queasysnail.net Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=none smtp.mailfrom=sd@queasysnail.net DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 034953D979 Date: Tue, 25 Apr 2017 17:12:48 +0200 From: Sabrina Dubroca To: "Jason A. Donenfeld" Cc: Netdev , LKML , David Miller , stable@vger.kernel.org, security@kernel.org Subject: Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec Message-ID: <20170425151248.GB25241@bistromath.localdomain> References: <20170421211448.16995-1-Jason@zx2c4.com> <20170425145340.GA25241@bistromath.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.2 (2017-04-18) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 25 Apr 2017 15:12:51 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-04-25, 17:08:28 +0200, Jason A. Donenfeld wrote: > Hi Sabrina, > > On Tue, Apr 25, 2017 at 4:53 PM, Sabrina Dubroca wrote: > > Ugh, good catch :/ > > > > AFAICT this patch doesn't really help, because NETIF_F_FRAGLIST > > doesn't get tested in paths that can lead to triggering this. > > You're right. This fixes the xmit() path, but not the receive path, > which appears to take skbs directly from the upper device. > > > I'll post a patch to allocate a properly-sized sg array. > > I just posted this series, which should fix things in a robust way: > > https://patchwork.ozlabs.org/patch/754861/ Yes, that prevents the overflow, but now you're just dropping packets. I'll review that later, let's fix the overflow without breaking connectivity for now. -- Sabrina