Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1169675AbdDXMPa (ORCPT ); Mon, 24 Apr 2017 08:15:30 -0400 Received: from frisell.zx2c4.com ([192.95.5.64]:55013 "EHLO frisell.zx2c4.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1046523AbdDXMPX (ORCPT ); Mon, 24 Apr 2017 08:15:23 -0400 MIME-Version: 1.0 In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DCFFD9487@AcuExch.aculab.com> References: <20170421211448.16995-1-Jason@zx2c4.com> <063D6719AE5E284EB5DD2968C1650D6DCFFD9487@AcuExch.aculab.com> From: "Jason A. Donenfeld" Date: Mon, 24 Apr 2017 14:15:19 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec To: David Laight Cc: "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "davem@davemloft.net" , "stable@vger.kernel.org" , "security@kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1364 Lines: 26 On Mon, Apr 24, 2017 at 1:02 PM, David Laight wrote: > ... > > Shouldn't skb_to_sgvec() be checking the number of fragments against > the size of the sg list? > The callers would then all need auditing to allow for failure. This has never been done before, since this is one of those operations that simply _shouldn't fail_ this late in the driver's path. There's an easy way to use a fixed size array of MAX_SKB_FRAGS+1, and then just not specify FRAGLIST as a device feature. Then the function succeeds every time, rather than dropping packets. Alternatively, if the array is being allocated dynamically (kmalloc), a call to skb_cow_data returns the number of fragments needed; since usually people using scattergather are going to be modifying the skb anyway, I believe this function should be being called anyway... It would be possible to do as you suggest, though, by using sg_is_last in skb_to_sgvec. In this case we'd need to change every call site of skb_to_sgvec to ensure the return value is being checked as well as making sure that the sglist is initialized with sg_init_table to ensure the last frag is properly marked. I wouldn't be opposed to this, though it is potentially error prone work. In any case, this patch here follows the pattern of the entire rest of the present-day kernel, so it ought to be merged as-is.