On 01/04/2018 06:10 AM, Vlastimil Babka wrote:
On 01/04/2018 02:57 PM, 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+76e7efc4748495855a4d@xxxxxxxxxxxxxxxxxxxxxxxxx
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(1514727386.271:7): avc: denied { map } for
pid=3485 comm="syzkaller426814" path="/root/syzkaller426814263" 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: 1 PID: 3485 at mm/page_alloc.c:3926
__alloc_pages_slowpath+0x1ffc/0x2d00 mm/page_alloc.c:3936
This is a warning about order >= MAX_ORDER.
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 3485 Comm: syzkaller426814 Not tainted 4.15.0-rc5+ #244
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:__alloc_pages_slowpath+0x1ffc/0x2d00 mm/page_alloc.c:3936
RSP: 0018:ffff8801c011f418 EFLAGS: 00010246
RAX: ffffed0038023ea4 RBX: 1ffff10038023ea4 RCX: 0000000000000000
RDX: ffff8801c011fa70 RSI: 0000000000000033 RDI: 0000000000000000
RBP: ffff8801c011f908 R08: 0000000000000000 R09: fffffffffff80f8a
R10: 0000000000000033 R11: 0000000000000033 R12: 0000000000000000
R13: ffff8801c011fad0 R14: 00000000014280c2 R15: ffff8801c011fa70
__alloc_pages_nodemask+0x9fb/0xd80 mm/page_alloc.c:4252
alloc_pages_current+0xb6/0x1e0 mm/mempolicy.c:2036
alloc_pages include/linux/gfp.h:492 [inline]
ion_system_contig_heap_allocate+0x40/0x2c0
drivers/staging/android/ion/ion_system_heap.c:374
And the allocation came from here. It should use smaller order, or
__NOWARN if this is some kind of opportunistic attempt. Maybe the order
comes all the way from userspace ioctl?
Yes, the order is coming directly from userspace as the size
requested for an Ion allocation. I think we do need to at least
pass __NOWARN for the system contig heap case.
Thanks,
Laura
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
