From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82CE7C433EF for ; Thu, 16 Sep 2021 10:43:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 640E06120F for ; Thu, 16 Sep 2021 10:43:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236925AbhIPKo5 (ORCPT ); Thu, 16 Sep 2021 06:44:57 -0400 Received: from mga14.intel.com ([192.55.52.115]:54334 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236403AbhIPKo4 (ORCPT ); Thu, 16 Sep 2021 06:44:56 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10108"; a="222192302" X-IronPort-AV: E=Sophos;i="5.85,298,1624345200"; d="scan'208";a="222192302" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2021 03:43:36 -0700 X-IronPort-AV: E=Sophos;i="5.85,298,1624345200"; d="scan'208";a="553817313" Received: from djustese-mobl.ger.corp.intel.com (HELO localhost) ([10.249.34.120]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2021 03:43:31 -0700 From: Jani Nikula To: Tvrtko Ursulin , Tim Gardner , linux-kernel@vger.kernel.org Cc: Joonas Lahtinen , Rodrigo Vivi , David Airlie , Daniel Vetter , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: zero fill vma name buffer In-Reply-To: <7a653532-046d-c68a-3dc9-ef2deaf455f9@linux.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20210915192318.2061-1-tim.gardner@canonical.com> <7a653532-046d-c68a-3dc9-ef2deaf455f9@linux.intel.com> Date: Thu, 16 Sep 2021 13:43:28 +0300 Message-ID: <87ee9ox0kv.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 16 Sep 2021, Tvrtko Ursulin wrote: > 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. strscpy() is preferred over both strncpy() and strlcpy(). :) BR, Jani. > > 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; >> -- Jani Nikula, Intel Open Source Graphics Center