WARNING in input_alloc_absinfo

WARNING in input_alloc_absinfo

[syzbot]

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+c382812c78d98ecd9fb8@syzkaller.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 ...

CPU: 1 PID: 4498 Comm: syz-executor465 Not tainted 4.16.0+ #87
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:17 [inline]
  dump_stack+0x185/0x1d0 lib/dump_stack.c:53
  panic+0x39d/0x940 kernel/panic.c:183
  __warn+0x40f/0x580 kernel/panic.c:547
  report_bug+0x72a/0x880 lib/bug.c:186
  fixup_bug arch/x86/kernel/traps.c:179 [inline]
  do_error_trap+0x1aa/0x600 arch/x86/kernel/traps.c:297
  do_invalid_op+0x46/0x50 arch/x86/kernel/traps.c:316
  invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
RIP: 0010:input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487
RSP: 0018:ffff88019651faa8 EFLAGS: 00010282
RAX: 0000000000000028 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: aaaaaaaaaaaab000 RDI: ffffea0000000000
RBP: ffff88019651fae0 R08: 0000000001080020 R09: 0000000000000002
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff8801a19ec140 R14: ffff88019796e198 R15: 0000000000000000
  uinput_abs_setup drivers/input/misc/uinput.c:507 [inline]
  uinput_ioctl_handler+0x38a2/0x39f0 drivers/input/misc/uinput.c:1035
  uinput_ioctl+0x9a/0xb0 drivers/input/misc/uinput.c:1047
  vfs_ioctl fs/ioctl.c:46 [inline]
  do_vfs_ioctl+0xaf0/0x2440 fs/ioctl.c:686
  SYSC_ioctl+0x1d2/0x260 fs/ioctl.c:701
  SyS_ioctl+0x54/0x80 fs/ioctl.c:692
  do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
RIP: 0033:0x440429
RSP: 002b:00007ffe9308d2b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000440429
RDX: 0000000000000000 RSI: 0000000040005504 RDI: 0000000000000003
RBP: 00000000006cb018 R08: 0000000000000001 R09: 00007ffe93080031
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004
R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
    (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: WARNING in input_alloc_absinfo

[Dmitry Torokhov]

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+c382812c78d98ecd9fb8@syzkaller.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.

> 
> CPU: 1 PID: 4498 Comm: syz-executor465 Not tainted 4.16.0+ #87
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x185/0x1d0 lib/dump_stack.c:53
>  panic+0x39d/0x940 kernel/panic.c:183
>  __warn+0x40f/0x580 kernel/panic.c:547
>  report_bug+0x72a/0x880 lib/bug.c:186
>  fixup_bug arch/x86/kernel/traps.c:179 [inline]
>  do_error_trap+0x1aa/0x600 arch/x86/kernel/traps.c:297
>  do_invalid_op+0x46/0x50 arch/x86/kernel/traps.c:316
>  invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:986
> RIP: 0010:input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487
> RSP: 0018:ffff88019651faa8 EFLAGS: 00010282
> RAX: 0000000000000028 RBX: 0000000000000000 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: aaaaaaaaaaaab000 RDI: ffffea0000000000
> RBP: ffff88019651fae0 R08: 0000000001080020 R09: 0000000000000002
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8801a19ec140 R14: ffff88019796e198 R15: 0000000000000000
>  uinput_abs_setup drivers/input/misc/uinput.c:507 [inline]
>  uinput_ioctl_handler+0x38a2/0x39f0 drivers/input/misc/uinput.c:1035
>  uinput_ioctl+0x9a/0xb0 drivers/input/misc/uinput.c:1047
>  vfs_ioctl fs/ioctl.c:46 [inline]
>  do_vfs_ioctl+0xaf0/0x2440 fs/ioctl.c:686
>  SYSC_ioctl+0x1d2/0x260 fs/ioctl.c:701
>  SyS_ioctl+0x54/0x80 fs/ioctl.c:692
>  do_syscall_64+0x309/0x430 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
> RIP: 0033:0x440429
> RSP: 002b:00007ffe9308d2b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 0000000000440429
> RDX: 0000000000000000 RSI: 0000000040005504 RDI: 0000000000000003
> RBP: 00000000006cb018 R08: 0000000000000001 R09: 00007ffe93080031
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000004
> R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
> 
> 
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
> 
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches

Thanks.

-- 
Dmitry

Re: WARNING in input_alloc_absinfo

[Dmitry Vyukov]

On Fri, Jun 29, 2018 at 11:59 PM,  <dmitry.torokhov@gmail.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....@gmail.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...@syzkaller.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

Re: WARNING in input_alloc_absinfo

[Dmitry Vyukov]

On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Fri, Jun 29, 2018 at 11:59 PM,  <dmitry.torokhov@gmail.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....@gmail.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...@syzkaller.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?

Re: WARNING in input_alloc_absinfo

[Dmitry Vyukov]

On Thu, Jul 26, 2018 at 11:40 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>> On Fri, Jun 29, 2018 at 11:59 PM,  <dmitry.torokhov@gmail.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....@gmail.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...@syzkaller.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()

Re: Re: WARNING in input_alloc_absinfo

[syzbot]

> On Thu, Jul 26, 2018 at 11:40 AM, Dmitry Vyukov <dvyukov@google.com>  
> wrote:
>> On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov <dvyukov@google.com>  
>> wrote:
>>> On Fri, Jun 29, 2018 at 11:59 PM,  <dmitry.torokhov@gmail.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....@gmail.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...@syzkaller.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()

Can't find the corresponding bug.


> --
> You received this message because you are subscribed to the Google  
> Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an  
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit  
> https://groups.google.com/d/msgid/syzkaller-bugs/CACT4Y%2Ba%2Bc6skSwS8WfY9GUs9mnjmf_aa7C5crW-m2Jb54ZbyuA%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

Re: Re: WARNING in input_alloc_absinfo

[Dmitry Vyukov]

On Tue, Aug 7, 2018 at 4:28 PM, syzbot
<syzbot+@syzkaller.appspotmail.com> wrote:
>> On Thu, Jul 26, 2018 at 11:40 AM, Dmitry Vyukov <dvyukov@google.com>
>> wrote:
>>>
>>> On Mon, Jul 2, 2018 at 11:30 AM, Dmitry Vyukov <dvyukov@google.com>
>>> wrote:
>>>>
>>>> On Fri, Jun 29, 2018 at 11:59 PM,  <dmitry.torokhov@gmail.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....@gmail.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...@syzkaller.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()
>
>
> Can't find the corresponding bug.

Now with syzbot email in CC:

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