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: <CAG_fn=XFqMoN-saedAH7EaYgB14GfoQg5whBPuYTaDeoUTL4vw@mail.gmail.com>
Date:   Tue, 20 Sep 2016 11:25:00 +0200
From:   Alexander Potapenko <glider@...gle.com>
To:     syzkaller <syzkaller@...glegroups.com>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        Dave Airlie <airlied@...hat.com>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Rob Clark <robdclark@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Kostya Serebryany <kcc@...gle.com>,
        Guenter Roeck <groeck@...gle.com>
Subject: Re: drm: NULL pointer dereference in drm_mode_object_find()

On Tue, Sep 20, 2016 at 11:21 AM, David Herrmann <dh.herrmann@...il.com> wrote:
> Hi
>
> On Mon, Sep 5, 2016 at 10:30 AM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>> On Fri, Aug 19, 2016 at 7:10 PM, Alexander Potapenko <glider@...gle.com> wrote:
>>> Hello,
>>>
>>> the program below triggers a NULL deref in DRM code when ran on QEMU:
>>>
>>> ===================================================
>>> BUG: unable to handle kernel NULL pointer dereference at           (null)
>>> IP: [<     inline     >] __list_add ./include/linux/list.h:44
>>> IP: [<     inline     >] list_add_tail ./include/linux/list.h:77
>>> IP: [<     inline     >] __mutex_lock_common kernel/locking/mutex.c:543
>>> IP: [<ffffffff818e850f>] __mutex_lock_slowpath+0x6f/0x100
>>> kernel/locking/mutex.c:824
>>> PGD 1c555067 PUD 1c554067 PMD 0
>>> Oops: 0002 [#1] SMP
>>> Modules linked in:
>>> CPU: 0 PID: 2517 Comm: crash_drm_mode_ Not tainted 4.8.0-rc2+ #1157
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> task: ffff88001c40a700 task.stack: ffff88001c984000
>>> RIP: 0010:[<ffffffff818e850f>]  [<ffffffff818e850f>]
>>> __mutex_lock_slowpath+0x6f/0x100
>>> RSP: 0018:ffff88001c987cb0  EFLAGS: 00010282
>>> RAX: 0000000000000000 RBX: ffff88001d5212a0 RCX: 00000000c0000100
>>> RDX: 0000000000000001 RSI: ffff88001c40a700 RDI: ffff88001d5212a4
>>> RBP: ffff88001c987cf8 R08: ffff88001c984000 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88001c40a700
>>> R13: ffff88001d5212a4 R14: 00000000ffffffff R15: ffff88001d5212a8
>>> FS:  0000000000dc9880(0000) GS:ffff88001f000000(0000) knlGS:0000000000000000
>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 0000000000000000 CR3: 000000001c8a9000 CR4: 00000000000406f0
>>> Stack:
>>>  ffff88001d5212a8 0000000000000000 0000000000000000 ffffffff811a398f
>>>  ffff88001d5212a0 ffff88001d5212a0 0000000000000000 00000000cccccccc
>>>  ffffffff81a6eb20 ffff88001c987d10 ffffffff818e85ba ffff88001d521000
>>> Call Trace:
>>>  [<     inline     >] __mutex_fastpath_lock ./arch/x86/include/asm/mutex_64.h:28
>>>  [<ffffffff818e85ba>] mutex_lock+0x1a/0x30 kernel/locking/mutex.c:102
>>>  [<ffffffff8142dd23>] _object_find+0x23/0xc0 drivers/gpu/drm/drm_crtc.c:329
>>>  [<     inline     >] drm_mode_object_find drivers/gpu/drm/drm_crtc.c:360
>>>  [<     inline     >] drm_crtc_find ./include/drm/drm_crtc.h:2999
>>>  [<ffffffff8143502e>] drm_mode_page_flip_ioctl+0x4e/0x300
>>> drivers/gpu/drm/drm_crtc.c:5414
>>>  [<ffffffff81426bb2>] drm_ioctl+0x2a2/0x460 drivers/gpu/drm/drm_ioctl.c:721
>>>  [<     inline     >] vfs_ioctl fs/ioctl.c:43
>>>  [<ffffffff8119700d>] do_vfs_ioctl+0x8d/0x580 fs/ioctl.c:675
>>>  [<     inline     >] SYSC_ioctl fs/ioctl.c:690
>>>  [<ffffffff81197574>] SyS_ioctl+0x74/0x80 fs/ioctl.c:681
>>>  [<ffffffff818ea9db>] entry_SYSCALL_64_fastpath+0x13/0x8f
>>> arch/x86/entry/entry_64.S:207
>>> Code: e8 37 23 00 00 8b 03 83 f8 01 0f 84 95 00 00 00 48 8b 43 10 4c
>>> 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48>
>>> 89 20 4c 89 64 24 10 eb 19 49 c7 04 24 02 00 00 00 c6 43 04
>>> RIP  [<     inline     >] __list_add ./include/linux/list.h:44
>>> RIP  [<     inline     >] list_add_tail ./include/linux/list.h:77
>>> RIP  [<     inline     >] __mutex_lock_common kernel/locking/mutex.c:543
>>> RIP  [<ffffffff818e850f>] __mutex_lock_slowpath+0x6f/0x100
>>> kernel/locking/mutex.c:824
>>>  RSP <ffff88001c987cb0>
>>> CR2: 0000000000000000
>>> ---[ end trace 3cef4eb618ac6bb6 ]---
>>> ===================================================
>>>
>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>> #include <stdint.h>
>>> #include <string.h>
>>> #include <unistd.h>
>>>
>>> int main()
>>> {
>>>   int fd = open("/dev/dri/card0", 0);
>>>   mmap(0x20036000ul, 0x1000ul, 0x3ul, 0x32ul, 0xfffffffffffffffful, 0x0ul);
>>>   memcpy((void*)0x20036ad7,
>>>          "\x1e\xa4\x45\xdc\xca\x11\xff\x25\x72\x65\x7e\x4a\x56\x54\x35"
>>>          "\x67\xe3\x8b\x41\x5c\x6d\x69\xa5\xf9\x88\x29\xb8\xc9\x6a\x45"
>>>          "\x76\xa9\xe7\x14\xd1\xf6\xa3\x59\x07\x4d\xe5\xc8\x39\xbf\x33"
>>>          "\xb9\x3d\x21\xd1\xaf\x16\x4d\xbc\xbf\xb1\x0a\x92\x97\xd9\x91"
>>>          "\x4d\xd8\xf8\xa1\xa6\xa3\x20\x02\x2c\x5e\x8f\x87\x05\x8b\xeb"
>>>          "\x9a\xb9\xbc\xa6\x60\x45\x8d\x19\x01\x7d\xb7\xef\x64\x62\x2e"
>>>          "\x5e\x3d\xfe\x65\xbf\xe2\x80\x89\x36\x48\x73\xc6\xa2\x6e\xe2"
>>>          "\x1a\x8f\x1b\x11\x6f\x49\x20\xeb\x74\x2d\x41\xb9\x8b\xb4\x8e"
>>>          "\x8b\xf5\x6d\xb7\xb1\xa3\xcb\xc4\xc2\x7f\x6d\xef\x32\xef\xa7"
>>>          "\x1c\x17\x03\x60\x7b\x31\x1f\x66",
>>>          143);
>>>   ioctl(fd, 0xbb0ul, 0x20036ad7ul, 0, 0, 0);
>>>   return 0;
>>> }
>>>
>>> I build the ToT kernel (commit
>>> 952b159f2919a8d514f13999f9f463bddcc1dae7, Aug 18) with defconfig and
>>> CONFIG_DRM_VGEM=y.
>>
>> +dri-devel
>>
>> I am also hitting this on 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of
>> linux-next.
>
> Can you tell us which DRM driver this is? vgem does not specify
> DRIVER_MODESET, so the page-flip ioctl should not be hooked up. Also,
> the mmap() operation should fail on any GEM driver. *confused*
How do I check that?
> Thanks
> David
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@...glegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ