netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).