linux-kernel - Re: drm: GPF in drm

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: <CACT4Y+bHADthe+BrWadJWvL8VAmR7HBc0AgOHuCt0GB=p3j_sw@mail.gmail.com>
Date:   Sat, 26 Nov 2016 18:50:19 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     syzkaller <syzkaller@...glegroups.com>
Cc:     Daniel Vetter <daniel.vetter@...ll.ch>,
        David Airlie <airlied@...ux.ie>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: drm: GPF in drm_getcap

On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann <dh.herrmann@...il.com> wrote:
> Hi
>
> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>>> Hello,
>>>
>>> The following program triggers GPF in drm_getcap:
>>>
>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>> #include <fcntl.h>
>>> #include <stddef.h>
>>> #include <stdint.h>
>>> #include <sys/ioctl.h>
>>> #include <sys/stat.h>
>>> #include <sys/syscall.h>
>>> #include <sys/types.h>
>>> #include <unistd.h>
>>>
>>> int main()
>>> {
>>>   int fd = open("/dev/dri/card0", O_RDONLY);
>>>   uint64_t data[2] = {0x11, 0x80};
>>>   ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
>>>   return 0;
>>> }
>>>
>>>
>>> general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
>>> Modules linked in:
>>> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> task: ffff8800310dc540 task.stack: ffff88003cbc0000
>>> RIP: 0010:[<ffffffff834ca87b>]  [<ffffffff834ca87b>]
>>> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>> RSP: 0018:ffff88003cbc7c28  EFLAGS: 00010202
>>> RAX: 0000000000000058 RBX: ffff88003cbc7cf8 RCX: ffffc90001db0000
>>> RDX: 000000000000005d RSI: ffff88003cbc7cf8 RDI: 00000000000002c0
>>> RBP: ffff88003cbc7c50 R08: ffffed0007978fa1 R09: ffffed0007978fa0
>>> R10: ffff88003cbc7d07 R11: ffffed0007978fa1 R12: fffffffffffffff0
>>> R13: dffffc0000000000 R14: ffff88003bcc6850 R15: fffffffffffffff2
>>> FS:  00007fcbf4e03700(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000
>>> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 00000000006dce00 CR3: 0000000066135000 CR4: 00000000000006e0
>>> DR0: 000000000000001e DR1: 000000000000001e DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
>>> Stack:
>>>  ffff88003c26db00 ffff88003cbc7cf8 ffffffff875a3000 ffffffff88cf0ee0
>>>  fffffffffffffff2 ffff88003cbc7dc0 ffffffff834cb57c 000000000000e200
>>>  1ffff10000000001 ffffffff875a1ba0 ffffffff882ae930 0000000000000010
>>> Call Trace:
>>>  [<ffffffff834cb57c>] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
>>>  [<     inline     >] vfs_ioctl fs/ioctl.c:43
>>>  [<ffffffff818a331c>] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>>>  [<     inline     >] SYSC_ioctl fs/ioctl.c:690
>>>  [<ffffffff818a429f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>>>  [<ffffffff86e1a8c0>] entry_SYSCALL_64_fastpath+0x23/0xc1
>>> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
>>> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
>>> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
>>> RIP  [<ffffffff834ca87b>] drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>>  RSP <ffff88003cbc7c28>
>>> ---[ end trace c6e1afa8cd73b880 ]---
>>>
>>>
>>> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
>>
>> ping
>>
>> Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>
> I suspect this is because we run drm_for_each_crtc() in
> drm_getcap(DRM_PAGE_FLIP_TARGET) on a legacy driver (meaning
> mode_config is not initialized). @danvet, how about always
> initializing mode_config to 0/empty/dummy?
>
> Dmitry, what driver do you run this on? And is CONFIG_DRM_LEGACY enabled?


CONFIG_DRM_LEGACY is enabled.

How can I understand what driver is used?
This happens inside of qemu. This is the device:
crw-rw---T 1 root video 226, 0 Nov 26 17:45 /dev/dri/card0