Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1183338pxb; Thu, 16 Sep 2021 01:25:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZ4p4HRhEmCZ7moZpdSZ3ps9eB00pb48F8+Vo2PtpBqvFA2dN+YYo0e3C8LhagFGzUQ6Ua X-Received: by 2002:a92:d12:: with SMTP id 18mr2894026iln.287.1631780720957; Thu, 16 Sep 2021 01:25:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631780720; cv=none; d=google.com; s=arc-20160816; b=GfTePkENqG2j0gUQQ9c/wsqbruJ5Lt6glbd/XpCReAeyvrluqjkhu30QRycFdpIBb0 ELlX5RLqOHi6ohzeXvHkrK3Il1Fo251keZgFsPydvOo72UWvVsxXKL62YngTRPsZS/X+ sW5958LINGsLOxVGQ00iWfAQAG3enl8oqB5KArYC3pJoysWnw58w7W9+DkBprPR7ENwu /vXSfRYYBXo1NQoaBh8U1h0znAsFz0pG9+DhpcWHTYZSyBB0dwcrus3vdrLe1VYAOdFf autRCYSKXgrwY1QxuzDND6iZGdDQ56//LTypHfj+nkwpomq727+nzWzyQJ8H0lXe9sBm QFSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject; bh=LuidkdpKtqqZbIPV1wWwbaxSbvZkL2vu/GsAsI3a0WA=; b=fO94WZW1W7/SFft435vyr2pFGv6gRL7PdIRQltwVr10a7N59EOofe4VMiHKPTk9N2r lc8+wBy1B9Tevwdon9wbzUwQfUxSj0AxTfVUpp3n3akdfMaXAa30D9oSdbwuhhnVDkOe tCuTPFRTGRfOf3ja1e9wnQpxRxFRlitUzDOftVbcrywXfiozni5HNjKxGpE3R1nUpRoT K6f9GHC2aqK1OC5/vqAdZ4jo1/p4NeMVsH3bnDbFgvmJ08YgjcRfP3P/l8xof6SAyn3u yiAGYWr68ofL/PyU+IOLUz6UnhVUd69NW1CsIHxXgL7LVlG4VoIQQXWOMRHf1mw7OYhh GxcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c39si1982655jaf.12.2021.09.16.01.25.09; Thu, 16 Sep 2021 01:25:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235056AbhIPIYt (ORCPT + 99 others); Thu, 16 Sep 2021 04:24:49 -0400 Received: from mga01.intel.com ([192.55.52.88]:11423 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234904AbhIPIYt (ORCPT ); Thu, 16 Sep 2021 04:24:49 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10108"; a="244889786" X-IronPort-AV: E=Sophos;i="5.85,297,1624345200"; d="scan'208";a="244889786" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2021 01:23:25 -0700 X-IronPort-AV: E=Sophos;i="5.85,297,1624345200"; d="scan'208";a="516695771" Received: from ipoconno-mobl3.ger.corp.intel.com (HELO [10.213.234.111]) ([10.213.234.111]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2021 01:23:22 -0700 Subject: Re: [Intel-gfx] [PATCH] drm/i915: zero fill vma name buffer To: Tim Gardner , linux-kernel@vger.kernel.org Cc: Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org References: <20210915192318.2061-1-tim.gardner@canonical.com> From: Tvrtko Ursulin Organization: Intel Corporation UK Plc Message-ID: <7a653532-046d-c68a-3dc9-ef2deaf455f9@linux.intel.com> Date: Thu, 16 Sep 2021 09:23:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210915192318.2061-1-tim.gardner@canonical.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/09/2021 20:23, Tim Gardner wrote: > In capture_vma() Coverity complains of a possible buffer overrun. Even > though this is a static function where all call sites can be checked, > limiting the copy length could save some future grief. > > CID 93300 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW) > 4. fixed_size_dest: You might overrun the 16-character fixed-size string c->name > by copying name without checking the length. > 5. parameter_as_source: Note: This defect has an elevated risk because the > source argument is a parameter of the current function. > 1326 strcpy(c->name, name); > > Fix any possible overflows by using strncpy(). Zero fill the name buffer to > guarantee ASCII string NULL termination. > > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: David Airlie > Cc: Daniel Vetter > Cc: intel-gfx@lists.freedesktop.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Tim Gardner > --- > drivers/gpu/drm/i915/i915_gpu_error.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c > index 9cf6ac575de1..154df174e2d7 100644 > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -1297,10 +1297,11 @@ static bool record_context(struct i915_gem_context_coredump *e, > return simulated; > } > > +#define VMA_NAME_LEN 16 > struct intel_engine_capture_vma { > struct intel_engine_capture_vma *next; > struct i915_vma *vma; > - char name[16]; > + char name[VMA_NAME_LEN]; > }; > > static struct intel_engine_capture_vma * > @@ -1314,7 +1315,7 @@ capture_vma(struct intel_engine_capture_vma *next, > if (!vma) > return next; > > - c = kmalloc(sizeof(*c), gfp); > + c = kzalloc(sizeof(*c), gfp); > if (!c) > return next; > > @@ -1323,7 +1324,7 @@ capture_vma(struct intel_engine_capture_vma *next, > return next; > } > > - strcpy(c->name, name); > + strncpy(c->name, name, VMA_NAME_LEN-1); GCC is supposed to catch any problems here as you say in the commit message. But to fix I suggest a single line change to strlcpy(c->name, name, sizeof(c->name)) which always null terminates as bonus. Probably same in i915_vma_coredump_create() which with strncpy would have a theoretical chance of attempting to copy over a non-null-terminated string. Regards, Tvrtko > c->vma = vma; /* reference held while active */ > > c->next = next; >