Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp2470269ybg; Thu, 30 Jul 2020 23:54:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKnVQhLolwwfUeo5NIt/QC5LOeQm6C6NMvdwhUd3wz5URCzZbGsuNJ1I9U0D19ALKE71ci X-Received: by 2002:a50:fe0a:: with SMTP id f10mr2455255edt.264.1596178462031; Thu, 30 Jul 2020 23:54:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596178462; cv=none; d=google.com; s=arc-20160816; b=srhQtVSXo3Ekq19wZY3J8RuQ3u+czhfXuQSo1hE08cUXM9VZD3FTHEtySEKAslsTVP vLlRutQ0vAguJnjrwDvvQ19pe2PAOFGg/u1BztIyu1d/hfa7/8kmBvybrvJOs/YUB/8k QYVsVo70tL3Qon+qCZRaluaUJIeapOxBAr0dFDIDpdLE2FrtlECXkmkj68BzeQ9oAVds Zz5SIRtIcOB6yRnkt7CnPVPqFhJu19BGOTg56HjHqL1RD4xP2jaX/dTF4PJg1SsFbkxp h33FLth9v8EEVMObNJdNleZtg78pl2rVH/S46zzVrlv344eWyROReG0PgN3pRHSVWCyK PCiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=I3w0+uX0SgtN6tTduj1tyPtNs0to4h/hTtP2x3BwxHs=; b=iw83oCS2IKnziL+bXEbAtnE45+b1Guu78GKPVJ2dJAKMgV76jLWK7vEw2xZPWUGpgS O/dHasX6lg2lC2luerCy0VAy/JzhD79YFWvR05PUVNQaB8V2EYrQNpwBHaAw7eTXiG8p iD0mroqBtaV/8xM2QRGUch+VGthHOS1GqgqEJxa7hiLiRn1cVffb5eNLJUF2elmg8nij Jq2U2vt/dgUU/8jZW5hh9z3sL/UaG2EOLUT2Cb7hg4XWk07MEt2tBXHH2QZMq7kHLTSr 5BiEXZ1AHqXJLUFREqBC8Yjs1vi7q25YbLNnxAiuUDJKlHdIdKP9lmWgeDSy6pr7j+ko U4eQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="wHsdC/0f"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t2si4516741eje.689.2020.07.30.23.53.59; Thu, 30 Jul 2020 23:54:22 -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; dkim=pass header.i=@kernel.org header.s=default header.b="wHsdC/0f"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731384AbgGaGxf (ORCPT + 99 others); Fri, 31 Jul 2020 02:53:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:59280 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731224AbgGaGxf (ORCPT ); Fri, 31 Jul 2020 02:53:35 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 000FD207F5; Fri, 31 Jul 2020 06:53:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596178414; bh=fNT75IpsFv23vL5vXayzc9tXmlPArXQFzFYd85vUNc4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=wHsdC/0fAKiD9YbaIfsbFj8p03yJkr9qnBoWo/Ix5UbCr1RLfihp7pEzhGtHbguq1 /+FDpBO2nfeS+ZtSS/W9SOgSdCKVKLvWJj7x0Qj3xcRhHThBaXQK9DVnnYL5tnK/Bu baaUYQoJUnWUKqyyFkdRXWivQ8nvj9uuW3vAVtas= Date: Fri, 31 Jul 2020 08:53:22 +0200 From: Greg Kroah-Hartman To: Luben Tuikov Cc: Alex Deucher , Christian Koenig , Xiaojie Yuan , Thomas Zimmermann , Arnd Bergmann , David Airlie , Felix Kuehling , LKML , amd-gfx list , Nicholas Kazlauskas , Marek =?utf-8?B?T2zFocOhaw==?= , Hans de Goede , Trek , Maling list - DRI developers , Daniel Vetter , Alex Deucher , Evan Quan , Leo Liu , Peilin Ye , Dan Carpenter , linux-kernel-mentees@lists.linuxfoundation.org Subject: Re: [Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl() Message-ID: <20200731065322.GA1518178@kroah.com> References: <20200728192924.441570-1-yepeilin.cs@gmail.com> <30b2a31f-77c2-56c1-ecde-875c6eea99d5@gmail.com> <8c5cf518-12d2-7495-7822-c7ebf8e61972@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8c5cf518-12d2-7495-7822-c7ebf8e61972@amd.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 30, 2020 at 05:09:07PM -0400, Luben Tuikov wrote: > On 2020-07-29 9:49 a.m., Alex Deucher wrote: > > On Wed, Jul 29, 2020 at 4:11 AM Christian K?nig > > wrote: > >> > >> Am 28.07.20 um 21:29 schrieb Peilin Ye: > >>> Compiler leaves a 4-byte hole near the end of `dev_info`, causing > >>> amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace > >>> when `size` is greater than 356. > >>> > >>> In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which > >>> unfortunately does not initialize that 4-byte hole. Fix it by using > >>> memset() instead. > >>> > >>> Cc: stable@vger.kernel.org > >>> Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()") > >>> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") > >>> Suggested-by: Dan Carpenter > >>> Signed-off-by: Peilin Ye > >> > >> Reviewed-by: Christian K?nig > >> > >> I can't count how many of those we have fixed over the years. > >> > >> At some point we should probably document that using "= {}" or "= { 0 }" > >> in the kernel is a really bad idea and should be avoided. > > > > Moreover, it seems like different compilers seem to behave relatively > > differently with these and we often get reports of warnings with these > > on clang. When in doubt, memset. > > There are quite a few of those under drivers/gpu/drm, for "amd/", "scheduler/" > drm*.c files, > > $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *(|NULL|0) *}" \{\} \+ | wc -l > 374 > $_ > > Out of which only 16 are of the non-ISO C variety, "= {}", > > $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *}" \{\} \+ | wc -l > 16 > $_ > > Perhaps the latter are the more pressing ones, since it is a C++ initializer and not a ISO C one. It only matters when we care copying the data to userspace, if it all stays in the kernel, all is fine. thanks, greg k-h