SLAB warning in te_prep_mem_buffer() |
||
Issue description
I've spotted the following warning using syzkaller on a Pixel C while fuzzing the tlk_device ioctls:
------------[ cut here ]------------
WARNING: CPU: 3 PID: 488 at /mnt/host/source/src/third_party/kernel/v3.18/mm/slab_common.c:659 kmalloc_slab+0x3c/0xb0()
CPU: 3 PID: 488 Comm: syz-executor Tainted: G U 3.18.0 #89
Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
Call trace:
[<ffffffc00020b064>] dump_backtrace+0x0/0x17c /mnt/host/source/src/third_party/kernel/v3.18/arch/arm64/kernel/traps.c:91
[<ffffffc00020b1f8>] show_stack+0x18/0x24 /mnt/host/source/src/third_party/kernel/v3.18/arch/arm64/kernel/traps.c:173
[< inline >] __dump_stack /mnt/host/source/src/third_party/kernel/v3.18/lib/dump_stack.c:15
[<ffffffc00118b540>] dump_stack+0x94/0x100 /mnt/host/source/src/third_party/kernel/v3.18/lib/dump_stack.c:50
[<ffffffc00022c5b4>] warn_slowpath_common+0xbc/0xec /mnt/host/source/src/third_party/kernel/v3.18/kernel/panic.c:441
[<ffffffc00022c748>] warn_slowpath_null+0x2c/0x38 /mnt/host/source/src/third_party/kernel/v3.18/kernel/panic.c:474
[<ffffffc00039a1dc>] kmalloc_slab+0x38/0xb0 /mnt/host/source/src/third_party/kernel/v3.18/mm/slab_common.c:659
[<ffffffc0003cc180>] __kmalloc+0x24/0x368 /mnt/host/source/src/third_party/kernel/v3.18/mm/slab.c:3515
[< inline >] kmalloc /mnt/host/source/src/third_party/kernel/v3.18/include/linux/slab.h:442
[< inline >] kzalloc /mnt/host/source/src/third_party/kernel/v3.18/include/linux/slab.h:595
[< inline >] te_prep_mem_buffer /mnt/host/source/src/third_party/kernel/v3.18/security/tlk_driver/ote_memory.c:222
[<ffffffc0005f0348>] te_prep_mem_buffers+0x15c/0x838 /mnt/host/source/src/third_party/kernel/v3.18/security/tlk_driver/ote_memory.c:289
[<ffffffc0005ef61c>] te_open_session+0x110/0x350 /mnt/host/source/src/third_party/kernel/v3.18/security/tlk_driver/ote_comms.c:237
[< inline >] te_handle_trustedapp_ioctl /mnt/host/source/src/third_party/kernel/v3.18/security/tlk_driver/ote_device.c:389
[<ffffffc0005eeb24>] tlk_device_ioctl+0x264/0x6f0 /mnt/host/source/src/third_party/kernel/v3.18/security/tlk_driver/ote_device.c:482
[< inline >] vfs_ioctl /mnt/host/source/src/third_party/kernel/v3.18/fs/ioctl.c:43
[<ffffffc0003f4d04>] do_vfs_ioctl+0x818/0x854 /mnt/host/source/src/third_party/kernel/v3.18/fs/ioctl.c:598
[< inline >] SYSC_ioctl /mnt/host/source/src/third_party/kernel/v3.18/fs/ioctl.c:613
[<ffffffc0003f4dac>] SyS_ioctl+0x6c/0xb0 /mnt/host/source/src/third_party/kernel/v3.18/fs/ioctl.c:604
---[ end trace 97d1adaba70dcaeb ]---
It's being triggered here:
654 struct kmem_cache *kmalloc_slab(size_t size, gfp_t flags)
655 {
656 int index;
657
658 if (unlikely(size > KMALLOC_MAX_SIZE)) {
659 WARN_ON_ONCE(!(flags & __GFP_NOWARN));
660 return NULL;
661 }
Apparently some allocation failure handling should be performed here:
197 static int te_prep_mem_buffer(struct te_oper_param *param,
198 struct te_session *session)
199 {
200 struct page **pages = NULL;
...
219 nr_pages = (((uintptr_t)start & (PAGE_SIZE - 1)) +
220 (length + PAGE_SIZE - 1)) >> PAGE_SHIFT;
221
222 vmas = kzalloc(sizeof(*vmas) * nr_pages, GFP_KERNEL);
,
Sep 27 2016
,
Sep 27 2016
Logged on the Android side as b/31768963 |
||
►
Sign in to add a comment |
||
Comment 1 by glider@chromium.org
, Sep 19 2016Yet another report: The following warning has been reported while fuzzing Ryu kernel with syzkaller: WARNING: CPU: 1 PID: 17268 at mm/slab_common.c:659 kmalloc_slab+0x3c/0xb0() CPU: 1 PID: 17268 Comm: syz-executor Tainted: G U W 3.18.0-g56d9ed7 #1 Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT) Call trace: [<ffffffc00020ad2c>] dump_backtrace+0x0/0x17c arch/arm64/kernel/traps.c:90 [<ffffffc00020aec0>] show_stack+0x18/0x24 arch/arm64/kernel/traps.c:172 [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffc001156f34>] dump_stack+0x94/0x100 lib/dump_stack.c:50 [<ffffffc00022bf04>] warn_slowpath_common+0xbc/0xec kernel/panic.c:441 [<ffffffc00022c098>] warn_slowpath_null+0x2c/0x38 kernel/panic.c:474 [<ffffffc0003927e4>] kmalloc_slab+0x38/0xb0 mm/slab_common.c:659 [<ffffffc0003c41f4>] __kmalloc+0x24/0x368 mm/slab.c:3515 [< inline >] kmalloc include/linux/slab.h:442 [< inline >] te_handle_trustedapp_ioctl security/tlk_driver/ote_device.c:460 [<ffffffc0005e364c>] tlk_device_ioctl+0x450/0x830 security/tlk_driver/ote_device.c:518 [< inline >] vfs_ioctl fs/ioctl.c:43 [<ffffffc0003ecc40>] do_vfs_ioctl+0x818/0x854 fs/ioctl.c:598 [< inline >] SYSC_ioctl fs/ioctl.c:613 [<ffffffc0003ecce8>] SyS_ioctl+0x6c/0xb0 fs/ioctl.c:604 ---[ end trace ea17fe3206361c8c ]--- kmalloc() with size > KMALLOC_MAX_SIZE is being called here: 352 static long te_handle_trustedapp_ioctl(struct file *file, 353 unsigned int ioctl_num, unsigned long ioctl_param) 354 { ... 459 if (operation->list_count > 0) { 460 caller_params = kmalloc(sizeof(struct te_oper_param) * 461 operation->list_count, GFP_KERNEL); 462 if (!caller_params) { 463 pr_err("%s: failed to allocate caller params\n", __func__); 464 err = -ENOMEM; 465 goto error; 466 } 467 } Guess it's not good that we allow tlk_device to allocate an arbitrary amount of memory?