From: Dan Carpenter <dan.carpenter@oracle.com>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: "Enrico Weigelt, metux IT consult" <lkml@metux.net>,
Joe Perches <joe@perches.com>, zhanglin <zhang.lin16@zte.com.cn>,
davem@davemloft.net, cocci <cocci@systeme.lip6.fr>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
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()
Date: Thu, 21 Nov 2019 15:07:33 +0300 [thread overview]
Message-ID: <20191121120733.GF5604@kadam> (raw)
In-Reply-To: <20191121111917.GE29650@unicorn.suse.cz>
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)
regards,
dan carpenter
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Michal Kubecek <mkubecek@suse.cz>
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,
pablo@netfilter.org, 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,
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 15:07:33 +0300 [thread overview]
Message-ID: <20191121120733.GF5604@kadam> (raw)
In-Reply-To: <20191121111917.GE29650@unicorn.suse.cz>
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)
regards,
dan carpenter
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
next prev parent reply other threads:[~2019-11-21 12:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-26 7:54 [PATCH] net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol() zhanglin
2019-10-26 14:24 ` Dan Carpenter
2019-10-26 15:52 ` Joe Perches
2019-10-26 18:21 ` David Miller
2019-10-26 19:40 ` Joe Perches
2019-10-26 19:40 ` [Cocci] " Joe Perches
2019-10-26 20:17 ` Julia Lawall
2019-10-26 20:17 ` Julia Lawall
2019-11-21 10:23 ` Enrico Weigelt, metux IT consult
2019-11-21 10:23 ` Enrico Weigelt, metux IT consult
2019-11-21 11:19 ` Michal Kubecek
2019-11-21 11:19 ` Michal Kubecek
2019-11-21 11:58 ` Julia Lawall
2019-11-21 11:58 ` Julia Lawall
2019-11-21 12:07 ` Dan Carpenter [this message]
2019-11-21 12:07 ` Dan Carpenter
2019-11-21 13:38 ` Michal Kubecek
2019-11-21 13:38 ` Michal Kubecek
2019-11-21 20:40 ` Julia Lawall
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=20191121120733.GF5604@kadam \
--to=dan.carpenter@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cocci@systeme.lip6.fr \
--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=mkubecek@suse.cz \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.