Received: by 10.213.65.68 with SMTP id h4csp226802imn; Sat, 17 Mar 2018 01:29:08 -0700 (PDT) X-Google-Smtp-Source: AG47ELuXvVEdWGe2Lcwbzg9xVPCsZrWvQvajXiWJH7JI+oqNpIID7r0ZKx9FB+q583OxEuja07jZ X-Received: by 10.98.6.133 with SMTP id 127mr4173273pfg.28.1521275348690; Sat, 17 Mar 2018 01:29:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521275348; cv=none; d=google.com; s=arc-20160816; b=uZUni1ppV6e3i0gsVhsAh94YYb8EYWBLio7RMmlNmM+f7JHdyQJY+0vcXWVTj3pY3H KiOoZ8wT8+JAAohE8iI7o2xYRTgIkhfcrpaU3rzwlLeR1vPGqTqnw99Dhzd5OuQKIP/8 gHJsM3lDMjC3nwAGE233N2HWIkZKU1M1SadrX6CtXMiHEDDBGwMwPsEJDeQ+3yGY1B/A C1xw6PXQAHn4O8unpTl417cyHM+gIKWyzmaZ/Z4MBa/XtOy+r3bDHpWNlgsKWQEaZveh 5ABb3lg0fk/hd8QyKZZt5hwE90oUw6cC/nyjfEJbl0TcHsGFUwKx9jGZvV6YZU3N3Iey KPdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=u/t1007053CtIr+65fAz04cZpBUzZqA1FjjsftOPY18=; b=Xe1Qrv7z/K1lrgNuADxrI2tHJjiavd/We0n7pd1wYUke63Mxeog80idG43Y/lOAs4u RtFp5GFF76TfRHhmfSE3SBeT44eOCuKuOAHI1b7sSpJQHt6wAAn7ukY1wwtzlHCoz9so U3lY5NkUAJtBnjC09ImlaQYgIqXg9bN+Bel+q1i9odzZyWQ4hz11ECNLksQ8djtvRV0d ZGLjaqH1u+sasNKoo7LNkEIMIIedOB899Q4aqAgvQYgCnlIUVWrBbDhf7ICugoGjdsJH /YQF4oyRGbP1BcnlDIexxwsi4iv2Ad0h+cwvl3f05GLhgy8HzYmeMgfLED1Vsr2r8hMZ 9jbA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r15si4342273pgq.324.2018.03.17.01.28.12; Sat, 17 Mar 2018 01:29:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752131AbeCQIZO (ORCPT + 99 others); Sat, 17 Mar 2018 04:25:14 -0400 Received: from bmailout3.hostsharing.net ([176.9.242.62]:34729 "EHLO bmailout3.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751693AbeCQIZM (ORCPT ); Sat, 17 Mar 2018 04:25:12 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout3.hostsharing.net (Postfix) with ESMTPS id A3967100B02DC; Sat, 17 Mar 2018 09:25:10 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 0F44A42A26; Sat, 17 Mar 2018 09:25:09 +0100 (CET) Date: Sat, 17 Mar 2018 09:25:09 +0100 From: Lukas Wunner To: Rasmus Villemoes Cc: Laura Abbott , Linus Walleij , Kees Cook , linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Mathias Duckeck , Nandor Han , Semi Malinen , Patrice Chotard Subject: Re: [PATCH 1/4] gpio: Remove VLA from gpiolib Message-ID: <20180317082509.GA2579@wunner.de> References: <20180310001021.6437-1-labbott@redhat.com> <20180310001021.6437-2-labbott@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 12, 2018 at 04:00:36PM +0100, Rasmus Villemoes wrote: > On 2018-03-10 01:10, Laura Abbott wrote: > > @@ -2887,14 +2909,30 @@ void gpiod_set_array_value_complex(bool raw, bool can_sleep, > > > > while (i < array_size) { > > struct gpio_chip *chip = desc_array[i]->gdev->chip; > > - unsigned long mask[BITS_TO_LONGS(chip->ngpio)]; > > - unsigned long bits[BITS_TO_LONGS(chip->ngpio)]; > > + unsigned long *mask; > > + unsigned long *bits; > > int count = 0; > > > > + mask = kmalloc_array(BITS_TO_LONGS(chip->ngpio), > > + sizeof(*mask), > > + can_sleep ? GFP_KERNEL : GFP_ATOMIC); > > + > > + if (!mask) > > + return; > > + > > + bits = kmalloc_array(BITS_TO_LONGS(chip->ngpio), > > + sizeof(*bits), > > + can_sleep ? GFP_KERNEL : GFP_ATOMIC); > > + > > + if (!bits) { > > + kfree(mask); > > + return; > > + } > > + > > if (!can_sleep) > > WARN_ON(chip->can_sleep); > > > > - memset(mask, 0, sizeof(mask)); > > + memset(mask, 0, sizeof(*mask)); > > Other random thoughts: maybe two allocations for each loop iteration is > a bit much. Maybe do a first pass over the array and collect the maximal > chip->ngpio, do the memory allocation and freeing outside the loop (then > you'd of course need to preserve the memset() with appropriate length > computed). And maybe even just do one allocation, making bits point at > the second half. I think those are great ideas because the function is kind of a hotpath and usage of VLAs was motivated by the desire to make it fast. I'd go one step further and store the maximum ngpio of all registered chips in a global variable (and update it in gpiochip_add_data_with_key()), then allocate 2 * max_ngpio once before entering the loop (as you've suggested). That would avoid the first pass to determine the maximum chip->ngpio. In most systems max_ngpio will be < 64, so one or two unsigned longs depending on the arch's bitness. FWIW, to achieve a stack overflow the platform or a driver need to specify a huge number of GPIOs for a chip. So the exploitability is limited, but of course it's still better to get rid of the VLAs. Running v2 of this patch through checkpatch --strict results in a few "Alignment should match open parenthesis" and one "Please don't use multiple blank lines" complaint, granted those are nits but it may be worth fixing them up front lest the usual suspects come along and submit bikeshedding patches. Thanks, Lukas