linux-kernel - Re: WARNING in input_alloc

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: <CACT4Y+a+c6skSwS8WfY9GUs9mnjmf_aa7C5crW-m2Jb54ZbyuA@mail.gmail.com>
Date:   Tue, 7 Aug 2018 16:27:49 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        linux-input@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        rydberg@...math.org
Subject: Re: WARNING in input_alloc_absinfo

On Thu, Jul 26, 2018 at 11:40 AM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
> On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>> On Fri, Jun 29, 2018 at 11:59 PM,  <dmitry.torokhov@...il.com> wrote:
>>> On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote:
>>>>
>>>> On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov
>>>> <dmitry....@...il.com> wrote:
>>>> > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote:
>>>> >> Hello,
>>>> >>
>>>> >> syzbot found the following crash on:
>>>> >>
>>>> >> HEAD commit:    d2d741e5d189 kmsan: add initialization for shmem pages
>>>> >> git tree:       https://github.com/google/kmsan.git/master
>>>> >> console output:
>>>> >> https://syzkaller.appspot.com/x/log.txt?x=1775bae7800000
>>>> >> kernel config:
>>>> >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f
>>>> >> dashboard link:
>>>> >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8
>>>> >> compiler:       clang version 7.0.0 (trunk 329391)
>>>> >> syzkaller
>>>> >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae7800000
>>>> >> C reproducer:
>>>> >> https://syzkaller.appspot.com/x/repro.c?x=1733255b800000
>>>> >>
>>>> >> IMPORTANT: if you fix the bug, please add the following tag to the
>>>> >> commit:
>>>> >> Reported-by: syzbot+c38281...@...kaller.appspotmail.com
>>>> >>
>>>> >> RBP: 00000000006cb018 R08: 0000000000000001 R09: 00007ffe93080031
>>>> >> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004
>>>> >> R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
>>>> >> ------------[ cut here ]------------
>>>> >> input_alloc_absinfo(): kcalloc() failed?
>>>> >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487
>>>> >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487
>>>> >> Kernel panic - not syncing: panic_on_warn set ...
>>>> >
>>>> > Hmm, so there is not really a problem as far as I am concerned. We do
>>>> > generate a warning if we can't allocate memory for absinfo,  as this is
>>>> > really unexpected, but the case is handled properly by the callers so
>>>> > there is no reason for us to go belly up here.
>>>>
>>>> Note to myself: ping this bug when "include/asm-generic/bug.h: clarify
>>>> valid uses of WARN()" is fully merged.
>>>
>>>
>>> No, this warning will still be there even after the "clarifying" patch is
>>> merged. It does not check user inputs, it warns that the system is so low on
>>> memory that we could not allocate measly amount needed for absinfo. Treat it
>>> as you treat OOM warnings from kmalloc() itself.
>>
>> Hi Dmitry,
>>
>> kmalloc does not produce WARNING on OOM. The rule is not only about
>> invalid inputs, it's also about any transient conditions and "WARNING
>> only for kernel bugs".
>>
>> To put this in larger context, being able to distinguish kernel bugs
>> from non-bugs is a very important and practically useful capability,
>> which in particular enables systematic testing, but also makes things
>> simpler for all kernel users. There must be a very significant reason
>> to abandon this capability. What is that reason in this case?
>>
>> I also don't understand what is so special about this case. If we want
>> user message for kmalloc failures, kmalloc is the right place for such
>> warning, rather than a random call site out of thousands. Consider,
>> the allocation failure can happen on the very next or previous kmalloc
>> call, and user won't be warned. The rest of the kernel (including the
>> rest of input sybsystem) does not warn on allocation failures, so that
>> looks like what we need to do here as well. Or, if there is something
>> very special about this particular kmalloc call site, something that
>> makes it different from thousands of other call sites, why don't you
>> want to replace it with pr_err which would both give the diagnostics
>> but also not block systematic testing? Which looks like a win-win to
>> me.
>>
>> Thanks
>
>
> So, Dmitry, do you mind fixing this in the name of unblocking kernel testing?


Let's tell syzbot about the pending fix:

#syz fix: Input: do not use WARN() in input_alloc_absinfo()