From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Eric Dumazet <eric.dumazet@gmail.com>,
Greg Hackmann <ghackmann@google.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>,
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
Florian Westphal <fw@strlen.de>,
Michal Kubecek <mkubecek@suse.cz>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
netdev@vger.kernel.org
Subject: Re: [PATCH v2] netfilter: properly initialize xt_table_info structure
Date: Thu, 17 May 2018 12:09:08 +0200 [thread overview]
Message-ID: <20180517100908.GA3150@kroah.com> (raw)
In-Reply-To: <a8fadcf4-c2dd-7465-9b41-189eb97a3dd2@gmail.com>
On Thu, May 17, 2018 at 02:55:42AM -0700, Eric Dumazet wrote:
>
>
> On 05/17/2018 02:34 AM, Greg Kroah-Hartman wrote:
> > When allocating a xt_table_info structure, we should be clearing out the
> > full amount of memory that was allocated, not just the "header" of the
> > structure. Otherwise odd values could be passed to userspace, which is
> > not a good thing.
> >
> > Cc: stable <stable@vger.kernel.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > v2: use kvzalloc instead of kvmalloc/memset pair, as suggested by Michal Kubecek
> >
> > net/netfilter/x_tables.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> > index cb7cb300c3bc..cd22bb9b66f3 100644
> > --- a/net/netfilter/x_tables.c
> > +++ b/net/netfilter/x_tables.c
> > @@ -1183,11 +1183,10 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
> > * than shoot all processes down before realizing there is nothing
> > * more to reclaim.
> > */
> > - info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > + info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > if (!info)
> > return NULL;
> >
> > - memset(info, 0, sizeof(*info));
> > info->size = size;
> > return info;
> > }
> >
>
> I am curious, what particular path does not later overwrite the whole zone ?
The path back was long, adding Greg Hackman who helped to debug this to
the To: to confirm that I got this correct...
In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
can be larger than the size of the structure itself.
Then the data is copied to userspace in copy_entries_to_user() for ipv4
and v6, and that's where the "bad data" was noticed (a researcher was
using a kernel patch to determine what the data was)
Greg, that's the correct path here, right?
> Do not get me wrong, this is not fast path, but these blobs can be huge.
Yeah, I bet, but for "normal" cases the size should be small and all
should be fine.
thanks,
greg k-h
next prev parent reply other threads:[~2018-05-17 10:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-17 8:44 [PATCH] netfilter: properly initialize xt_table_info structure Greg Kroah-Hartman
2018-05-17 8:59 ` Michal Kubecek
2018-05-17 9:29 ` Greg Kroah-Hartman
2018-05-17 9:34 ` [PATCH v2] " Greg Kroah-Hartman
2018-05-17 9:55 ` Eric Dumazet
2018-05-17 10:09 ` Greg Kroah-Hartman [this message]
2018-05-17 10:42 ` Jan Engelhardt
2018-05-17 13:20 ` Greg Kroah-Hartman
2018-05-18 9:27 ` Florian Westphal
2018-05-18 11:04 ` Greg Kroah-Hartman
2018-05-26 14:54 ` Greg Kroah-Hartman
[not found] ` <CANZU63WyNL4qUJx2eS3gokPMBJLn5=C4-bnOSEF5trX3jGngUA@mail.gmail.com>
2018-05-31 8:24 ` Florian Westphal
2018-05-31 8:51 ` Greg Kroah-Hartman
2018-05-31 9:07 ` Florian Westphal
2018-05-31 10:11 ` Greg Kroah-Hartman
[not found] ` <CANZU63VE7fWNL+PJrLp7-5PBS6R6RQPvhw2QgqAK8NhX4uQc9Q@mail.gmail.com>
2018-05-31 11:23 ` Greg Kroah-Hartman
2018-05-31 11:32 ` Michal Kubecek
2018-05-31 11:55 ` Michal Kubecek
2018-05-31 16:25 ` Greg Kroah-Hartman
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=20180517100908.GA3150@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=coreteam@netfilter.org \
--cc=eric.dumazet@gmail.com \
--cc=fw@strlen.de \
--cc=ghackmann@google.com \
--cc=kadlec@blackhole.kfki.hu \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/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).