linux-kernel - Re: WARNING: kmalloc bug in input_mt_init

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: <20180924184158.GA156847@dtor-ws>
Date:   Mon, 24 Sep 2018 11:41:58 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Christopher Lameter <cl@...ux.com>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        syzbot+87829a10073277282ad1@...kaller.appspotmail.com,
        Pekka Enberg <penberg@...nel.org>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Henrik Rydberg <rydberg@...math.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Linux-MM <linux-mm@...ck.org>
Subject: Re: WARNING: kmalloc bug in input_mt_init_slots

On Mon, Sep 24, 2018 at 03:55:04PM +0000, Christopher Lameter wrote:
> On Mon, 24 Sep 2018, Dmitry Vyukov wrote:
> 
> > On Mon, Sep 24, 2018 at 5:08 PM, Christopher Lameter <cl@...ux.com> wrote:
> > > On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
> > >
> > >> What was the motivation behind that WARNING about large allocations in
> > >> kmalloc? Why do we want to know about them? Is the general policy that
> > >> kmalloc calls with potentially large size requests need to use NOWARN?
> > >> If this WARNING still considered useful? Or we should change it to
> > >> pr_err?
> > >
> > > In general large allocs should be satisfied by the page allocator. The
> > > slab allocators are used for allocating and managing small objects. The
> > > page allocator has mechanisms to deal with large objects (compound pages,
> > > multiple page sized allocs etc).
> >
> > I am asking more about the status of this warning. If it fires in
> > input_mt_init_slots(), does it mean that input_mt_init_slots() needs
> > to be fixed? If not, then we need to change this warning to something
> > else.
> 
> Hmmm.. kmalloc falls back to the page allocator already?
> 
> See
> 
> static __always_inline void *kmalloc(size_t size, gfp_t flags)
> {
>         if (__builtin_constant_p(size)) {

It would not be a constant here though.

>                 if (size > KMALLOC_MAX_CACHE_SIZE)
>                         return kmalloc_large(size, flags);
> 
> 
> Note that this uses KMALLOC_MAX_CACHE_SIZE which should be smaller than
> KMALLOC_MAX_SIZE.
> 
> 
> How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
> are larger than the maximum allowed by the page allocator. Thus the warning
> and the NULL return.

The size in this particular case is being derived from a value passed
from userspace. Input core does not care about any limits on size of
memory kmalloc() can support and is perfectly happy with getting NULL
and telling userspace to go away with their silly requests by returning
-ENOMEM.

For the record: I definitely do not want to pre-sanitize size neither in
uinput nor in input core.

Thanks.

-- 
Dmitry