Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp603093ybg; Sun, 26 Jul 2020 15:12:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy/qjrgVq0vgwyKtWgo61e2KoVR6N1YtRocXYxDKRj1nJodqSSLIXUkCEY/p9lLlsAh5c+u X-Received: by 2002:aa7:d653:: with SMTP id v19mr9940629edr.258.1595801540803; Sun, 26 Jul 2020 15:12:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595801540; cv=none; d=google.com; s=arc-20160816; b=UUqAdOhTJ/MJfCY2kAR+8LdIi+LDlACTLRcn2QQOVWQuWDnTZxh73B3wFynVkp+TVd Oey189RESlfxEjTHPnQfABsd6bZ4RybWWzYZxCZEqhg4sx0+MeCLExB/71cpQJkIMKTY FNi7/P9gBjiKfNXjnkdPnEgCMGPme+Y1L3oX0Rvpc2JumKwHvscKWOc41MTAWqYtNJXs EC/JIasOZSQXoqDhX6ZP9WONbLlDnda5wxauzzuRbYC/tY/aClzCGzdkYWWehI+00q14 tUg9sGSdf59WrntdyOOvQK+74EaCkHHOJNFdjXXA610Qs2ZE65P2eji9t7dKRvzMcmJE pkqQ== 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-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=l+m57ZHhB/TL+mNKzCWw9MQOnMddRGGKCNVFGAfPttg=; b=Wszsm6QYvh3Wx5dX67anDs74kPQVVT+mg9h00h0ZI4uzkJc+Fdgt1fCXQRL+Sg7K8m d2RAtC4a/AByd5A9qsWBNnLAiqKnl0Dg2aeXJIr+71jngfgNhD2dz69AepL/VqPQ6Haf wSp6yHavMuXrFx8KHLmqRxRYY7lJe34JW7ociklRHu/EM4cJhBGoGi1gP1nj/ce8ggrc aM3c0hx1k0sN8ySBPOYuQ65c3zXPgGkulA8KPd6VYvoW0SA18nOUllTI+OnSFc9agE7M Vninb63JITOkQG0cSvGhyBkLebzURQhL+g52ibKtTQjj1azMZU1QZ4aPGcQA8WsRJ6ZW WIeQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=PSBrJrva; 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 v11si1072599edy.276.2020.07.26.15.11.59; Sun, 26 Jul 2020 15:12: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; dkim=pass (test mode) header.i=@ideasonboard.com header.s=mail header.b=PSBrJrva; 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 S1727064AbgGZWIg (ORCPT + 99 others); Sun, 26 Jul 2020 18:08:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726636AbgGZWIf (ORCPT ); Sun, 26 Jul 2020 18:08:35 -0400 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E733C0619D2; Sun, 26 Jul 2020 15:08:35 -0700 (PDT) Received: from pendragon.ideasonboard.com (81-175-216-236.bb.dnainternet.fi [81.175.216.236]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 60DE151D; Mon, 27 Jul 2020 00:08:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1595801311; bh=KUaPOkg636bLdNE8/asczb6N8L2ExnhjaO2k2jCo0LQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PSBrJrvay92ecq4JbixGxKIabJQmc4pZJaNk3A/wXXfD3Ekkbfpt7ZT6g2Y8a0057 /CfKIjl0AnCKZ3jw5eSwIWM8oliHSnhewGDEZy0sr4Mjz/s6eIajbulW7/E0mI5ee2 /cvTxgegR9ug5m2pbBZkLTCjthrHkLQewsX4SGnw= Date: Mon, 27 Jul 2020 01:08:23 +0300 From: Laurent Pinchart To: Peilin Ye Cc: Mauro Carvalho Chehab , Greg Kroah-Hartman , syzkaller-bugs@googlegroups.com, Hans Verkuil , Sakari Ailus , Arnd Bergmann , Vandana BN , Ezequiel Garcia , Niklas =?utf-8?Q?S=C3=B6derlund?= , linux-kernel-mentees@lists.linuxfoundation.org, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [Linux-kernel-mentees] [PATCH] media/v4l2-core: Fix kernel-infoleak in video_put_user() Message-ID: <20200726220823.GI28704@pendragon.ideasonboard.com> References: <20200726164439.48973-1-yepeilin.cs@gmail.com> <20200726173044.GA14755@pendragon.ideasonboard.com> <20200726180752.GA49356@PWN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200726180752.GA49356@PWN> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peilin, On Sun, Jul 26, 2020 at 02:07:52PM -0400, Peilin Ye wrote: > On Sun, Jul 26, 2020 at 08:30:44PM +0300, Laurent Pinchart wrote: > > Hi Peilin, > > > > Thank you for the patch. > > > > On Sun, Jul 26, 2020 at 12:44:39PM -0400, Peilin Ye wrote: > > > video_put_user() is copying uninitialized stack memory to userspace. Fix > > > it by initializing `vb32` using memset(). > > > > What makes you think this will fix the issue ? When initializing a > > structure at declaration time, the fields that are not explicitly > > specified should be initialized to 0 by the compiler. See > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbclx01/strin.htm: > > Hi Mr. Pinchart! > > First of all, syzbot tested this patch, and it says it's "OK": > > https://syzkaller.appspot.com/bug?extid=79d751604cb6f29fbf59 > > > If a structure variable is partially initialized, all the uninitialized > > structure members are implicitly initialized to zero no matter what the > > storage class of the structure variable is. See the following example: > > > > struct one { > > int a; > > int b; > > int c; > > }; > > > > void main() { > > struct one z1; // Members in z1 do not have default initial values. > > static struct one z2; // z2.a=0, z2.b=0, and z2.c=0. > > struct one z3 = {1}; // z3.a=1, z3.b=0, and z3.c=0. > > } > > Yes, I understand that. I can safely printk() all members of that struct > without triggering a KMSAN warning, which means they have been properly > initialized. > > However, if I do something like: > > char *p = (char *)&vb32; > int i; > > for (i = 0; i < sizeof(struct vb32); i++, p++) > printk("*(p + i): %d", *(p + i)); > > This tries to print out `vb32` as "raw memory" one byte at a time, and > triggers a KMSAN warning somewhere in the middle (when `i` equals to 25 > or 26). > > According to a previous discussion with Mr. Kroah-Hartman, as well as > this LWN article: > > "Structure holes and information leaks" > https://lwn.net/Articles/417989/ > > Initializing a struct by assigning (both partially or fully) leaves the > "padding" part of it uninitialized, thus potentially leads to kernel > information leak if the structure in question is going to be copied to > userspace. > > memset() sets these "uninitialized paddings" to zero, therefore (I > think) should solve the problem. You're absolutely right. I wasn't aware the compiler wouldn't initialize holes in the structure. Thank you for educating me :-) For the patch, Reviewed-by: Laurent Pinchart -- Regards, Laurent Pinchart