WARNING in ion_ioctl

[syzbot]

Hello,

syzkaller hit the following crash on
71ee203389f7cb1c1927eab22b95baa01405791c
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.
C reproducer is attached
syzkaller reproducer is attached. See https://goo.gl/kgGztJ
for information about syzkaller reproducers


IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+fa2d5f...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.

audit: type=1400 audit(1514734723.062:7): avc: denied { map } for
pid=3502 comm="syzkaller809746" path="/root/syzkaller809746698" dev="sda1"
ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
WARNING: CPU: 0 PID: 3502 at drivers/staging/android/ion/ion-ioctl.c:73
ion_ioctl+0x2db/0x380 drivers/staging/android/ion/ion-ioctl.c:73
Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 3502 Comm: syzkaller809746 Not tainted 4.15.0-rc5+ #154
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+0x194/0x257 lib/dump_stack.c:53
panic+0x1e4/0x41c kernel/panic.c:183
__warn+0x1dc/0x200 kernel/panic.c:547
report_bug+0x211/0x2d0 lib/bug.c:184
fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
fixup_bug arch/x86/kernel/traps.c:247 [inline]
do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
RIP: 0010:ion_ioctl+0x2db/0x380 drivers/staging/android/ion/ion-ioctl.c:73
RSP: 0018:ffff8801bfce7ca8 EFLAGS: 00010293
RAX: ffff8801bfea00c0 RBX: 0000000000000018 RCX: ffffffff8410f0fb
RDX: 0000000000000000 RSI: 0000000020002018 RDI: ffff8801bfce7cdc
RBP: ffff8801bfce7d40 R08: 0000000000000000 R09: ffffed0037f9cf9e
R10: 0000000000000003 R11: ffffed0037f9cf9d R12: 1ffff10037f9cf97
R13: 00000000c0184908 R14: ffff8801bfce7d18 R15: dffffc0000000000
C_SYSC_ioctl fs/compat_ioctl.c:1473 [inline]
compat_SyS_ioctl+0x151/0x2a30 fs/compat_ioctl.c:1419
do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129
RIP: 0023:0xf7f92c79
RSP: 002b:00000000ffe832ec EFLAGS: 00000213 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00000000c0184908
RDX: 0000000020002000 RSI: 00000000000000b6 RDI: 0000000020002000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.com.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.

[Greg KH]

On Thu, Jan 04, 2018 at 05:57:01AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 71ee203389f7cb1c1927eab22b95baa01405791c
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+fa2d5f...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> audit: type=1400 audit(1514734723.062:7): avc: denied { map } for
> pid=3502 comm="syzkaller809746" path="/root/syzkaller809746698" dev="sda1"
> ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
> WARNING: CPU: 0 PID: 3502 at drivers/staging/android/ion/ion-ioctl.c:73
> ion_ioctl+0x2db/0x380 drivers/staging/android/ion/ion-ioctl.c:73
> Kernel panic - not syncing: panic_on_warn set ...

This is to be expected when you pass in a crappy ion ioctl structure.

So don't do that :)

Yeah, it's a harsh warning, but I think the userspace developers like it
to ensure they got their implementation correct.

After the warning is thrown, all keeps working just fine.

thanks,

greg k-h

[Dmitry Vyukov]

Hi Greg,

Or, don't do WARNINGs on EINVAL and do pr_warn instead, as useful but
also enables automated kernel testing with non-tainted reports, which
is kinda a useful property.

[Greg KH]

Sure, that would be the sane thing to do, but this is staging android
code, the exact opposite of "sane" at the moment :)

thanks,

greg k-h

[Dan Carpenter]

On Thu, Jan 04, 2018 at 03:13:01PM +0100, Dmitry Vyukov wrote:

With pr_warn() you have to impliment the _ONCE() logic yourself which
is sort of a pain.

regards,
dan carpenter

[Laura Abbott]

From past experience, pr_warn was too subtle for some developers but
I'm more interested in the fuzzing at this point so I'll see about
just switching it to a pr_warn_once.

Thanks,
Laura

[Dan Carpenter]

Oh.. Duh to me... I didn't even know pr_warn_once() existed. Cool.

regards,
dan carpenter

[Dmitry Vyukov]

If it's so bad that it's not even ready for testing and has lots of
know bugs, then I will just go and disable it on syzbot. Just say.
But then it will never become production-ready until we re-enable
testing and go through this cleaning process later.

But I would expect that if the code is in mainline, even if in
staging, we should productionize it as quickly as possible, in
particular using fuzzing as guidance.
And in the end pr_warn can even provide a more informative error
message as compared to the WARNING with cpu number, process id,
register values and the stack trace with is always the same for the
ioctl.