netdev - Re: [PATCH v2] netfilter: properly initialize xt_table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LSU.2.20.1805171232210.30649@n3.vanv.qr>
Date:   Thu, 17 May 2018 12:42:00 +0200 (CEST)
From:   Jan Engelhardt <jengelh@...i.de>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
cc:     Eric Dumazet <eric.dumazet@...il.com>,
        Greg Hackmann <ghackmann@...gle.com>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>,
        Florian Westphal <fw@...len.de>,
        Michal Kubecek <mkubecek@...e.cz>,
        netfilter-devel@...r.kernel.org, coreteam@...filter.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH v2] netfilter: properly initialize xt_table_info
 structure


On Thursday 2018-05-17 12:09, Greg Kroah-Hartman wrote:
>> > --- 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;
>>
>> I am curious, what particular path does not later overwrite the whole zone ?
>
>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"

If the kernel incorrectly copies more bytes than it should, isn't that
a sign that may be going going past the end of the info buffer?
(And thus, zeroing won't truly fix the issue)

And if the kernel copies too few (because it just does not have more
data than userspace is requesting), what remains in the user buffer
is the garbage that originally was there.