cocci.inria.fr archive mirror
 help / color / mirror / Atom feed
From: Michal Kubecek <mkubecek@suse.cz>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Cc: jakub.kicinski@netronome.com, ast@kernel.org,
	natechancellor@gmail.com, jiang.xuexin@zte.com.cn,
	cocci <cocci@systeme.lip6.fr>,
	f.fainelli@gmail.com, daniel@iogearbox.net,
	john.fastabend@gmail.com, lirongqing@baidu.com,
	maxime.chevallier@bootlin.com, vivien.didelot@gmail.com,
	dan.carpenter@oracle.com, wang.yi59@zte.com.cn, hawk@kernel.org,
	arnd@arndb.de, jiri@mellanox.com, xue.zhihong@zte.com.cn,
	zhanglin <zhang.lin16@zte.com.cn>,
	Thomas Gleixner <tglx@linutronix.de>,
	bpf@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, linyunsheng@huawei.com,
	pablo@netfilter.org, Joe Perches <joe@perches.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	davem@davemloft.net
Subject: Re: [Cocci] [PATCH] net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol()
Date: Thu, 21 Nov 2019 12:19:17 +0100	[thread overview]
Message-ID: <20191121111917.GE29650@unicorn.suse.cz> (raw)
In-Reply-To: <bc150c6a-6d3e-ff01-e40e-840e8a385bda@metux.net>

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.

If the structure is not going to be copied to userspace (or otherwise
exposed), using the initializer is fully sufficient and looks cleaner.

Michal Kubecek
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

  reply	other threads:[~2019-11-21 11:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1572076456-12463-1-git-send-email-zhang.lin16@zte.com.cn>
2019-10-26 19:40 ` [Cocci] [PATCH] net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol() Joe Perches
2019-10-26 20:17   ` Julia Lawall
2019-11-21 10:23   ` Enrico Weigelt, metux IT consult
2019-11-21 11:19     ` Michal Kubecek [this message]
2019-11-21 11:58       ` Julia Lawall
2019-11-21 12:07       ` Dan Carpenter
2019-11-21 13:38         ` Michal Kubecek
2019-11-21 20:40           ` Julia Lawall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191121111917.GE29650@unicorn.suse.cz \
    --to=mkubecek@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=cocci@systeme.lip6.fr \
    --cc=dan.carpenter@oracle.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hawk@kernel.org \
    --cc=jakub.kicinski@netronome.com \
    --cc=jiang.xuexin@zte.com.cn \
    --cc=jiri@mellanox.com \
    --cc=joe@perches.com \
    --cc=john.fastabend@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linyunsheng@huawei.com \
    --cc=lirongqing@baidu.com \
    --cc=lkml@metux.net \
    --cc=maxime.chevallier@bootlin.com \
    --cc=natechancellor@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vivien.didelot@gmail.com \
    --cc=wang.yi59@zte.com.cn \
    --cc=xue.zhihong@zte.com.cn \
    --cc=zhang.lin16@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).