From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1948498AbdDYOxx (ORCPT ); Tue, 25 Apr 2017 10:53:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52968 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1948460AbdDYOxo (ORCPT ); Tue, 25 Apr 2017 10:53:44 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 784A03B71F 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 784A03B71F Date: Tue, 25 Apr 2017 16:53:40 +0200 From: Sabrina Dubroca To: "Jason A. Donenfeld" Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, davem@davemloft.net, stable@vger.kernel.org, security@kernel.org Subject: Re: [PATCH] macsec: avoid heap overflow in skb_to_sgvec Message-ID: <20170425145340.GA25241@bistromath.localdomain> References: <20170421211448.16995-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170421211448.16995-1-Jason@zx2c4.com> 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 14:53:43 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2017-04-21, 23:14:48 +0200, Jason A. Donenfeld wrote: > While this may appear as a humdrum one line change, it's actually quite > important. An sk_buff stores data in three places: > > 1. A linear chunk of allocated memory in skb->data. This is the easiest > one to work with, but it precludes using scatterdata since the memory > must be linear. > 2. The array skb_shinfo(skb)->frags, which is of maximum length > MAX_SKB_FRAGS. This is nice for scattergather, since these fragments > can point to different pages. > 3. skb_shinfo(skb)->frag_list, which is a pointer to another sk_buff, > which in turn can have data in either (1) or (2). > > The first two are rather easy to deal with, since they're of a fixed > maximum length, while the third one is not, since there can be > potentially limitless chains of fragments. Fortunately dealing with > frag_list is opt-in for drivers, so drivers don't actually have to deal > with this mess. For whatever reason, macsec decided it wanted pain, and > so it explicitly specified NETIF_F_FRAGLIST. > > Because dealing with (1), (2), and (3) is insane, most users of sk_buff > doing any sort of crypto or paging operation calls a convenient function > called skb_to_sgvec (which happens to be recursive if (3) is in use!). > This takes a sk_buff as input, and writes into its output pointer an > array of scattergather list items. Sometimes people like to declare a > fixed size scattergather list on the stack; othertimes people like to > allocate a fixed size scattergather list on the heap. However, if you're > doing it in a fixed-size fashion, you really shouldn't be using > NETIF_F_FRAGLIST too (unless you're also ensuring the sk_buff and its > frag_list children arent't shared and then you check the number of > fragments in total required.) > > Macsec specifically does this: > > size += sizeof(struct scatterlist) * (MAX_SKB_FRAGS + 1); > tmp = kmalloc(size, GFP_ATOMIC); > *sg = (struct scatterlist *)(tmp + sg_offset); > ... > sg_init_table(sg, MAX_SKB_FRAGS + 1); > skb_to_sgvec(skb, sg, 0, skb->len); > > Specifying MAX_SKB_FRAGS + 1 is the right answer usually, but not if you're > using NETIF_F_FRAGLIST, in which case the call to skb_to_sgvec will > overflow the heap, and disaster ensues. 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. I'll post a patch to allocate a properly-sized sg array. -- Sabrina