netdev - Re: [Cocci] [PATCH] net: Zeroing the structure ethtool_wolinfo in ethtool_get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191121133817.GF29650@unicorn.suse.cz>
Date:   Thu, 21 Nov 2019 14:38:17 +0100
From:   Michal Kubecek <mkubecek@...e.cz>
To:     Dan Carpenter <dan.carpenter@...cle.com>
Cc:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
        Joe Perches <joe@...ches.com>,
        zhanglin <zhang.lin16@....com.cn>, davem@...emloft.net,
        cocci <cocci@...teme.lip6.fr>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        jakub.kicinski@...ronome.com, ast@...nel.org,
        jiang.xuexin@....com.cn, f.fainelli@...il.com,
        daniel@...earbox.net, john.fastabend@...il.com,
        lirongqing@...du.com, maxime.chevallier@...tlin.com,
        vivien.didelot@...il.com, wang.yi59@....com.cn, hawk@...nel.org,
        arnd@...db.de, jiri@...lanox.com, xue.zhihong@....com.cn,
        natechancellor@...il.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, linyunsheng@...wei.com,
        pablo@...filter.org, bpf@...r.kernel.org
Subject: Re: [Cocci] [PATCH] net: Zeroing the structure ethtool_wolinfo in
 ethtool_get_wol()

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