Received: by 10.213.65.68 with SMTP id h4csp4460imn; Tue, 10 Apr 2018 14:56:10 -0700 (PDT) X-Google-Smtp-Source: AIpwx48JjwLz/Bk8loKqPYK9isssOdfopI8SvJ52Zh9gzWCJBYtAqtJ/hxPN+xF2kDi9XCsyEpmF X-Received: by 10.101.96.205 with SMTP id r13mr1495638pgv.427.1523397370750; Tue, 10 Apr 2018 14:56:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523397370; cv=none; d=google.com; s=arc-20160816; b=s4TGeEaTETR8kOHjrSnKEygq5Y/VZiap7nrA3WxexUQyu9Fe+51iG6Nf+mlW+TFyng qapSMddKlQcIioZ8OTWEhbU0P7LjB4kwx2COqaVwXEOBU6keBzRmPMYOvurI7rdD0d02 yTfUcgVUC9YYGkacxafpdeuaRM0gPhxu+80eg+ByHNCZkv7BEsvaq1WL6LFDIb4mPOUo AibCzKTrUSSRKcvyPFPgHD6R7XoJTY5n6pMeOnVkRxcYG3oYXzirEuCwAMIYal5RExXM P2g7/+/VG39A3CETQeT7Zub32Y5EPqlQv68BWI/BHQlkKMOW+ic138oP682BlLgK99vl WI3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=Ebtv7zbmt8FlFhkr60155qkgVpLXFfWHOK7tt956aOo=; b=kiY4uFRLKqyfvx+Tg2m9A3GsmzvQUxjm3t3TOzEI0qYZf+nx5+QWkPCKSvPPXAGWJF 1/enf8tOR58m/yqmIrhhrFjW+mGt/1DaE7oS1KaQZ+Fqmrkd1PJHUkMOvHjRYeb95D25 omo0tuYEUgbtrPwkkGcH6PSQe0sYsY6qS8TzvA5QLTWioVi2HH13Igb7Sc+LGnhsH2Ky sRTT6Wp3dIai8eeQLDhsRCyezoJ7SqWZVwUpaofGkuqNpyQ2+Nk6SkCcsXGQNZwsBMJT 1AAxZB/qiicnrWIiFPJUk3DUt9c2ZPo5pRbZC7rfopAenU5jeXaTx+gdDBHXpE5IExaq YTvA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bg11-v6si3509467plb.171.2018.04.10.14.55.30; Tue, 10 Apr 2018 14:56:10 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751888AbeDJVwk (ORCPT + 99 others); Tue, 10 Apr 2018 17:52:40 -0400 Received: from mail-qt0-f196.google.com ([209.85.216.196]:44018 "EHLO mail-qt0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751522AbeDJVwj (ORCPT ); Tue, 10 Apr 2018 17:52:39 -0400 Received: by mail-qt0-f196.google.com with SMTP id s48so15123508qtb.10 for ; Tue, 10 Apr 2018 14:52:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ebtv7zbmt8FlFhkr60155qkgVpLXFfWHOK7tt956aOo=; b=somqaItcScnYY/Ss5jmMM5WXsuLhMhPclmQdbb91C/N4gT66FNi+UX1ictHh2LKMXb sMpJYYsdpV3H41Jk6Zxh0VA0ZG31iKjx1i/WhJuUmXbi2Lbj1M8qFeVV7KxtfU1LvG+V iptKSzA/ZPX0gQ27bVkV5encBsroxO1Yr7P6yRUfgWmsGmHXpiXMgFdqPWddtRmwgy/R S23XnJi3iHiD7HHhw8lVv08QsyP2hSEDCXi5zL9xfDinZLLIDHe49P943Eco04I7tdvN cPunl7gQJB76iL+D0EFUr16arENLJ3JLJxKtLRabdVVjozMgN7W1WmWzVVAwbq5l7bsf 8/Og== X-Gm-Message-State: ALQs6tDVT9yvFaf0kgA3NHyUKHFKFKNnekUYi1ITEfxGmgY4Gx9Td6RR UolnV8b60DXS6d3kYX7cD9Wp5g== X-Received: by 10.200.27.3 with SMTP id y3mr3545332qtj.161.1523397158592; Tue, 10 Apr 2018 14:52:38 -0700 (PDT) Received: from ?IPv6:2601:602:9802:a8dc:4eb2:6dae:ab32:e5b0? ([2601:602:9802:a8dc:4eb2:6dae:ab32:e5b0]) by smtp.gmail.com with ESMTPSA id z19sm2969911qka.39.2018.04.10.14.52.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Apr 2018 14:52:37 -0700 (PDT) Subject: Re: [PATCH] drm/i2c: tda998x: Remove VLA usage To: Russell King - ARM Linux Cc: David Airlie , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com, Kees Cook References: <20180409210703.3787-1-labbott@redhat.com> <20180409222141.GR16141@n2100.armlinux.org.uk> From: Laura Abbott Message-ID: <855433a0-72f5-df29-3a17-5c2016e988e1@redhat.com> Date: Tue, 10 Apr 2018 14:52:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180409222141.GR16141@n2100.armlinux.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/09/2018 03:21 PM, Russell King - ARM Linux wrote: > On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote: >> There's an ongoing effort to remove VLAs[1] from the kernel to eventually >> turn on -Wvla. The vla in reg_write_range is based on the length of data >> passed. The one use of a non-constant size for this range is bounded by >> the size buffer passed to hdmi_infoframe_pack which is a fixed size. >> Switch to this upper bound. > > Does this _really_ make it safer? What if the code is modified to write > more than 32 bytes in the future? > > Sorry, I don't think this is safer at all. > Yeah I wasn't 100% sure about this one. Elsewhere, we've added bounds checks against the new static size buffer so we could do that here to ensure we don't overrun the stack if we do need to write more than 32 bytes in the future. Another option is to switch to a kmalloc buffer. Are either of those options acceptable to you or do you have a better idea of how to get rid of the VLA? Thanks, Laura