drm: GPF in drm_getcap
On 28/11/16 03:55 PM, Daniel Vetter wrote: > On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann > wrote: >> On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov wrote: >>> grep "card0" dmesg: >>> [5.298617] device: 'card0': device_add >>> [5.298946] PM: Adding info for No Bus:card0 >>> [6.436178] device: 'card0': device_add >>> [6.436488] PM: Adding info for No Bus:card0 >>> >>> >>> # ls -l /dev/dri/card0 >>> crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0 >>> >>> # ls -lt /sys/class/drm/card0/device/ >>> ls: cannot access /sys/class/drm/card0/device/: No such file or directory >>> >>> # ls -lt /sys/class/drm/card0/device/driver >>> ls: cannot access /sys/class/drm/card0/device/driver: No such file or >>> directory >> >> Looks like vgem. Something like this should help: >> >> https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2 >> >> I wonder whether it would be more appropriate to return -ENOTSUPP rather >> than 0. Can't see how that would matter FWIW. > Seems a bit overkill, but can't hurt. This is most likely a > regression, probably introduced in > > commit f837297ad82480024d3ad08cd84f6670bcafa862 > Author: Michel Dänzer > Date: Mon Aug 8 16:23:39 2016 +0900 > > drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2 > > Michel, can you pls take care of this? Either with a minimal fix, or > by adopting David's patch? Can't we just use David's patch as-is? If not, I think Dmitry or someone else would be better equipped than me to extract a minimal fix from it and test it. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
drm: GPF in drm_getcap
On Mon, Nov 28, 2016 at 8:14 AM, Michel Dänzer wrote: > On 28/11/16 03:55 PM, Daniel Vetter wrote: >> On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann >> wrote: >>> On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov >>> wrote: grep "card0" dmesg: [5.298617] device: 'card0': device_add [5.298946] PM: Adding info for No Bus:card0 [6.436178] device: 'card0': device_add [6.436488] PM: Adding info for No Bus:card0 # ls -l /dev/dri/card0 crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0 # ls -lt /sys/class/drm/card0/device/ ls: cannot access /sys/class/drm/card0/device/: No such file or directory # ls -lt /sys/class/drm/card0/device/driver ls: cannot access /sys/class/drm/card0/device/driver: No such file or directory >>> >>> Looks like vgem. Something like this should help: >>> >>> https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2 >>> >>> I wonder whether it would be more appropriate to return -ENOTSUPP rather >>> than 0. > > Can't see how that would matter FWIW. > > >> Seems a bit overkill, but can't hurt. This is most likely a >> regression, probably introduced in >> >> commit f837297ad82480024d3ad08cd84f6670bcafa862 >> Author: Michel Dänzer >> Date: Mon Aug 8 16:23:39 2016 +0900 >> >> drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2 >> >> Michel, can you pls take care of this? Either with a minimal fix, or >> by adopting David's patch? > > Can't we just use David's patch as-is? If not, I think Dmitry or someone > else would be better equipped than me to extract a minimal fix from it > and test it. I know nothing about DRM code. Reproducer is attached to the first email.
drm: GPF in drm_getcap
On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann wrote: > On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov wrote: >> grep "card0" dmesg: >> [5.298617] device: 'card0': device_add >> [5.298946] PM: Adding info for No Bus:card0 >> [6.436178] device: 'card0': device_add >> [6.436488] PM: Adding info for No Bus:card0 >> >> >> # ls -l /dev/dri/card0 >> crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0 >> >> # ls -lt /sys/class/drm/card0/device/ >> ls: cannot access /sys/class/drm/card0/device/: No such file or directory >> >> # ls -lt /sys/class/drm/card0/device/driver >> ls: cannot access /sys/class/drm/card0/device/driver: No such file or >> directory > > Looks like vgem. Something like this should help: > > https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2 > > I wonder whether it would be more appropriate to return -ENOTSUPP rather than > 0. Seems a bit overkill, but can't hurt. This is most likely a regression, probably introduced in commit f837297ad82480024d3ad08cd84f6670bcafa862 Author: Michel Dänzer Date: Mon Aug 8 16:23:39 2016 +0900 drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2 Michel, can you pls take care of this? Either with a minimal fix, or by adopting David's patch? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
drm: GPF in drm_getcap
Hi On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov wrote: > grep "card0" dmesg: > [5.298617] device: 'card0': device_add > [5.298946] PM: Adding info for No Bus:card0 > [6.436178] device: 'card0': device_add > [6.436488] PM: Adding info for No Bus:card0 > > > # ls -l /dev/dri/card0 > crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0 > > # ls -lt /sys/class/drm/card0/device/ > ls: cannot access /sys/class/drm/card0/device/: No such file or directory > > # ls -lt /sys/class/drm/card0/device/driver > ls: cannot access /sys/class/drm/card0/device/driver: No such file or > directory Looks like vgem. Something like this should help: https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2 I wonder whether it would be more appropriate to return -ENOTSUPP rather than 0. Thanks David
drm: GPF in drm_getcap
grep "card0" dmesg:
[5.298617] device: 'card0': device_add
[5.298946] PM: Adding info for No Bus:card0
[6.436178] device: 'card0': device_add
[6.436488] PM: Adding info for No Bus:card0
# ls -l /dev/dri/card0
crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0
# ls -lt /sys/class/drm/card0/device/
ls: cannot access /sys/class/drm/card0/device/: No such file or directory
# ls -lt /sys/class/drm/card0/device/driver
ls: cannot access /sys/class/drm/card0/device/driver: No such file or directory
On Sat, Nov 26, 2016 at 7:02 PM, David Herrmann
wrote:
> Hi
>
> On Sat, Nov 26, 2016 at 6:50 PM, Dmitry Vyukov wrote:
>> On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann
>> wrote:
>>> Hi
>>>
>>> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov
>>> wrote:
On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov
wrote:
> Hello,
>
> The following program triggers GPF in drm_getcap:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> 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: [#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: 8800310dc540 task.stack: 88003cbc
> RIP: 0010:[] []
> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
> RSP: 0018:88003cbc7c28 EFLAGS: 00010202
> RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
> RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
> RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
> R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
> R13: dc00 R14: 88003bcc6850 R15: fff2
> FS: 7fcbf4e03700() GS:88003ed0()
> knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 006dce00 CR3: 66135000 CR4: 06e0
> DR0: 001e DR1: 001e DR2:
> DR3: DR6: 0ff0 DR7: 0600
> Stack:
> 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
> fff2 88003cbc7dc0 834cb57c e200
> 1101 875a1ba0 882ae930 0010
> Call Trace:
> [] drm_ioctl+0x54c/0xaf0
> drivers/gpu/drm/drm_ioctl.c:728
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
> [< inline >] SYSC_ioctl fs/ioctl.c:690
> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
> [] 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 [] drm_getcap+0x34b/0x4f0
> drivers/gpu/drm/drm_ioctl.c:260
> RSP
> ---[ 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
>
> Usually by looking into `dmesg` and grepping for 'card0', or by inspecting:
>
> /sys/class/drm/card0/device/
>
> or more importantly looking at the symlink:
>
> /sys/class/drm/card0/device/driver
>
> Thanks
> David
drm: GPF in drm_getcap
Hi
On Sat, Nov 26, 2016 at 6:50 PM, Dmitry Vyukov wrote:
> On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann
> wrote:
>> Hi
>>
>> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov wrote:
>>> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote:
Hello,
The following program triggers GPF in drm_getcap:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#include
#include
#include
#include
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: [#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: 8800310dc540 task.stack: 88003cbc
RIP: 0010:[] []
drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
RSP: 0018:88003cbc7c28 EFLAGS: 00010202
RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
R13: dc00 R14: 88003bcc6850 R15: fff2
FS: 7fcbf4e03700() GS:88003ed0()
knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 006dce00 CR3: 66135000 CR4: 06e0
DR0: 001e DR1: 001e DR2:
DR3: DR6: 0ff0 DR7: 0600
Stack:
88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
fff2 88003cbc7dc0 834cb57c e200
1101 875a1ba0 882ae930 0010
Call Trace:
[] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
[< inline >] vfs_ioctl fs/ioctl.c:43
[] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
[< inline >] SYSC_ioctl fs/ioctl.c:690
[] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
[] 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 [] drm_getcap+0x34b/0x4f0
drivers/gpu/drm/drm_ioctl.c:260
RSP
---[ 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
Usually by looking into `dmesg` and grepping for 'card0', or by inspecting:
/sys/class/drm/card0/device/
or more importantly looking at the symlink:
/sys/class/drm/card0/device/driver
Thanks
David
drm: GPF in drm_getcap
On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann
wrote:
> Hi
>
> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov wrote:
>> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote:
>>> Hello,
>>>
>>> The following program triggers GPF in drm_getcap:
>>>
>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>> #include
>>>
>>> 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: [#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: 8800310dc540 task.stack: 88003cbc
>>> RIP: 0010:[] []
>>> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>> RSP: 0018:88003cbc7c28 EFLAGS: 00010202
>>> RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
>>> RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
>>> RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
>>> R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
>>> R13: dc00 R14: 88003bcc6850 R15: fff2
>>> FS: 7fcbf4e03700() GS:88003ed0() knlGS:
>>> CS: 0010 DS: ES: CR0: 80050033
>>> CR2: 006dce00 CR3: 66135000 CR4: 06e0
>>> DR0: 001e DR1: 001e DR2:
>>> DR3: DR6: 0ff0 DR7: 0600
>>> Stack:
>>> 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
>>> fff2 88003cbc7dc0 834cb57c e200
>>> 1101 875a1ba0 882ae930 0010
>>> Call Trace:
>>> [] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
>>> [< inline >] vfs_ioctl fs/ioctl.c:43
>>> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>>> [< inline >] SYSC_ioctl fs/ioctl.c:690
>>> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>>> [] 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 [] drm_getcap+0x34b/0x4f0
>>> drivers/gpu/drm/drm_ioctl.c:260
>>> RSP
>>> ---[ 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
drm: GPF in drm_getcap
Hi
On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov wrote:
> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers GPF in drm_getcap:
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>> #include
>>
>> 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: [#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: 8800310dc540 task.stack: 88003cbc
>> RIP: 0010:[] []
>> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>> RSP: 0018:88003cbc7c28 EFLAGS: 00010202
>> RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
>> RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
>> RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
>> R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
>> R13: dc00 R14: 88003bcc6850 R15: fff2
>> FS: 7fcbf4e03700() GS:88003ed0() knlGS:
>> CS: 0010 DS: ES: CR0: 80050033
>> CR2: 006dce00 CR3: 66135000 CR4: 06e0
>> DR0: 001e DR1: 001e DR2:
>> DR3: DR6: 0ff0 DR7: 0600
>> Stack:
>> 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
>> fff2 88003cbc7dc0 834cb57c e200
>> 1101 875a1ba0 882ae930 0010
>> Call Trace:
>> [] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
>> [< inline >] vfs_ioctl fs/ioctl.c:43
>> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>> [< inline >] SYSC_ioctl fs/ioctl.c:690
>> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>> [] 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 [] drm_getcap+0x34b/0x4f0
>> drivers/gpu/drm/drm_ioctl.c:260
>> RSP
>> ---[ 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?
Thanks
David
drm: GPF in drm_getcap
On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers GPF in drm_getcap:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> 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: [#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: 8800310dc540 task.stack: 88003cbc
> RIP: 0010:[] []
> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
> RSP: 0018:88003cbc7c28 EFLAGS: 00010202
> RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
> RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
> RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
> R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
> R13: dc00 R14: 88003bcc6850 R15: fff2
> FS: 7fcbf4e03700() GS:88003ed0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 006dce00 CR3: 66135000 CR4: 06e0
> DR0: 001e DR1: 001e DR2:
> DR3: DR6: 0ff0 DR7: 0600
> Stack:
> 88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
> fff2 88003cbc7dc0 834cb57c e200
> 1101 875a1ba0 882ae930 0010
> Call Trace:
> [] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
> [< inline >] SYSC_ioctl fs/ioctl.c:690
> [] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
> [] 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 [] drm_getcap+0x34b/0x4f0
> drivers/gpu/drm/drm_ioctl.c:260
> RSP
> ---[ end trace c6e1afa8cd73b880 ]---
>
>
> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
ping
Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
drm: GPF in drm_getcap
Hello,
The following program triggers GPF in drm_getcap:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#include
#include
#include
#include
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: [#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: 8800310dc540 task.stack: 88003cbc
RIP: 0010:[] []
drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
RSP: 0018:88003cbc7c28 EFLAGS: 00010202
RAX: 0058 RBX: 88003cbc7cf8 RCX: c90001db
RDX: 005d RSI: 88003cbc7cf8 RDI: 02c0
RBP: 88003cbc7c50 R08: ed0007978fa1 R09: ed0007978fa0
R10: 88003cbc7d07 R11: ed0007978fa1 R12: fff0
R13: dc00 R14: 88003bcc6850 R15: fff2
FS: 7fcbf4e03700() GS:88003ed0() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 006dce00 CR3: 66135000 CR4: 06e0
DR0: 001e DR1: 001e DR2:
DR3: DR6: 0ff0 DR7: 0600
Stack:
88003c26db00 88003cbc7cf8 875a3000 88cf0ee0
fff2 88003cbc7dc0 834cb57c e200
1101 875a1ba0 882ae930 0010
Call Trace:
[] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
[< inline >] vfs_ioctl fs/ioctl.c:43
[] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
[< inline >] SYSC_ioctl fs/ioctl.c:690
[] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
[] 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 [] drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
RSP
---[ end trace c6e1afa8cd73b880 ]---
On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
