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@xxxxxxxxxxxxxxx> > Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > --- > 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 ? Do not get me wrong, this is not fast path, but these blobs can be huge. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
