Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3249578ybc; Thu, 21 Nov 2019 05:42:21 -0800 (PST) X-Google-Smtp-Source: APXvYqzIC8wDDJxcysogFiWqGQvitjkSTNWYVIXKt+raqN038cl5/DD+DSmQpRdz08i4OrjWq9z9 X-Received: by 2002:a5d:49c4:: with SMTP id t4mr3863570wrs.226.1574343740754; Thu, 21 Nov 2019 05:42:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574343740; cv=none; d=google.com; s=arc-20160816; b=QfTMzVarGbGGJJ7KqFryWxWfjAEdfpXqtXLVvQ7N65RuZYZRQTUe4PYoI3C85Dr3VM XTzsR/FtH1I82f6Mk1lOBhSR8dS1COtGCMjzc6JgvZtBRlmPTPq+9hEv5iQeRw4ESe+d Y4Gvi+dSigwoP8JgiU21fK3J9cWHGOaDbVo8jjdnI4LrwR37PXYzljwg1tixI++38IYW z89Ksh5cIU38Rsuyyg9kJUfAXeAo6Soay2b3rBTCiRbxkF31+EXL3VjRtbJ0lXuTSFW8 24uqk8FUiZ3dctxpIF2QJBAi+7knyCERe0gdKKfaMVpBaT8Q2nXFImV2KmMHSC5eOsOO uCWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=BEW2Govh45gmYmrSJR+3sRJverrK4icLX604+Ew6RfY=; b=SY4tvzIQwAq4mZpY5BTcFls3lnuKz6tmKIBBlAsY7F/U21PsNea0YXjXqSMKrsDNkr 7MuWzqOS6eqIAyvMUR7leXWXNzNdJL6CIeMR/rQxK/MrgKgKJIlgxcxdxakvGwdc7Tn8 cUpYP6yx8rzX0dIvZ2KrhELnp2KWphQKDMBGY4Yq7u18Uz4bTMCfIsfkGXgZK8NACMrI UlGWqw9aS+P67MEghrLO876q4jQXfyZNJ6YloMr9Ic2zPTxYZINOHMn2cMiQ/tXGSiA9 XJVsZ2ICF6QiE4FDXRmm6V2SYl+T3jRn4XJ2pAR4oFh5mZhM1pOTVX9U3vZCvTIECOq5 1Ctg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l24si2014317edw.352.2019.11.21.05.41.54; Thu, 21 Nov 2019 05:42:20 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726944AbfKUNiW (ORCPT + 99 others); Thu, 21 Nov 2019 08:38:22 -0500 Received: from mx2.suse.de ([195.135.220.15]:45360 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726532AbfKUNiW (ORCPT ); Thu, 21 Nov 2019 08:38:22 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DB831B19F; Thu, 21 Nov 2019 13:38:18 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id 22A6EE03A4; Thu, 21 Nov 2019 14:38:17 +0100 (CET) Date: Thu, 21 Nov 2019 14:38:17 +0100 From: Michal Kubecek To: Dan Carpenter Cc: "Enrico Weigelt, metux IT consult" , Joe Perches , zhanglin , davem@davemloft.net, cocci , Andrew Morton , Thomas Gleixner , Linus Torvalds , jakub.kicinski@netronome.com, ast@kernel.org, jiang.xuexin@zte.com.cn, f.fainelli@gmail.com, daniel@iogearbox.net, john.fastabend@gmail.com, lirongqing@baidu.com, maxime.chevallier@bootlin.com, vivien.didelot@gmail.com, wang.yi59@zte.com.cn, hawk@kernel.org, arnd@arndb.de, jiri@mellanox.com, xue.zhihong@zte.com.cn, natechancellor@gmail.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linyunsheng@huawei.com, pablo@netfilter.org, bpf@vger.kernel.org Subject: Re: [Cocci] [PATCH] net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol() Message-ID: <20191121133817.GF29650@unicorn.suse.cz> References: <1572076456-12463-1-git-send-email-zhang.lin16@zte.com.cn> <20191121111917.GE29650@unicorn.suse.cz> <20191121120733.GF5604@kadam> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191121120733.GF5604@kadam> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 21, 2019 at 03:07:33PM +0300, Dan Carpenter wrote: > On Thu, Nov 21, 2019 at 12:19:17PM +0100, Michal Kubecek wrote: > > On Thu, Nov 21, 2019 at 11:23:34AM +0100, Enrico Weigelt, metux IT consult wrote: > > > On 26.10.19 21:40, Joe Perches wrote: > > > > On Sat, 2019-10-26 at 15:54 +0800, zhanglin wrote: > > > >> memset() the structure ethtool_wolinfo that has padded bytes > > > >> but the padded bytes have not been zeroed out. > > > > [] > > > >> diff --git a/net/core/ethtool.c b/net/core/ethtool.c > > > > [] > > > >> @@ -1471,11 +1471,13 @@ static int ethtool_reset(struct net_device *dev, char __user *useraddr) > > > >> > > > >> static int ethtool_get_wol(struct net_device *dev, char __user *useraddr) > > > >> { > > > >> - struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL }; > > > >> + struct ethtool_wolinfo wol; > > > >> > > > >> if (!dev->ethtool_ops->get_wol) > > > >> return -EOPNOTSUPP; > > > >> > > > >> + memset(&wol, 0, sizeof(struct ethtool_wolinfo)); > > > >> + wol.cmd = ETHTOOL_GWOL; > > > >> dev->ethtool_ops->get_wol(dev, &wol); > > > >> > > > >> if (copy_to_user(useraddr, &wol, sizeof(wol))) > > > > > > > > It seems likely there are more of these. > > > > > > > > Is there any way for coccinelle to find them? > > > > > > Just curios: is static struct initialization (on stack) something that > > > should be avoided ? I've been under the impression that static > > > initialization allows thinner code and gives the compiler better chance > > > for optimizations. > > > > Not in general. The (potential) problem here is that the structure has > > padding and it is as a whole (i.e. including the padding) copied to > > userspace. While I'm not aware of a compiler that wouldn't actually > > initialize the whole data block including the padding in this case, the > > C standard provides no guarantee about that so that to be sure we cannot > > leak leftover kernel data to userspace, we need to explicitly initialize > > the whole block. > > GCC will not always initialize the struct holes. This patch fixes a > real bug that GCC on my system (v7.4) Just checked (again) to be sure. No matter if the function is inlined or not, gcc 7.4.1 initializes the structure by one movl (of 0x5) and two movq (of 0x0), i.e. initializes all sizeof(struct ethtool_wolinfo) = 20 bytes including the padding. One could certainly construct examples where a real life compiler would only initialize the fields. That's why I said "in this case". Michal Kubecek