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 <sta...@vger.kernel.org>
> > Signed-off-by: Greg Kroah-Hartman <gre...@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.