kvm: GPF in kvm_lapic_latched_init

[Dmitry Vyukov]

Hello,

The following program triggers GPF in kvm_lapic_latched_init if run in
a parallel loop:
https://gist.githubusercontent.com/dvyukov/524b398f379440b21115/raw/9627095f57a72501fb51bf7565471d31732beeee/gistfile1.txt

kasan: GPF could be caused by NULL-ptr deref or user memory
accessgeneral protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 3 PID: 14426 Comm: a.out Not tainted 4.4.0-rc8+ #217
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880061099780 ti: ffff880062e30000 task.ti: ffff880062e30000
RIP: 0010:[<ffffffff81057171>] [<ffffffff81057171>]
kvm_arch_vcpu_ioctl+0xa31/0x2ef0
RSP: 0018:ffff880062e37900 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 1ffff1000c5c6f25 RCX: 1ffff1000c41b7cb
RDX: 000000000000001e RSI: 000000008040ae9f RDI: 00000000000000f0
RBP: ffff880062e37c10 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: ffff880062e37be8 R15: 0000000000000000
FS: 00007f4aa815f700(0000) GS:ffff88006d700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f4aa795de78 CR3: 00000000613c2000 CR4: 00000000000026e0
Stack:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000020006fe4 0000000041b58ab3 ffffffff86e2e588 ffffffff81056740
0000000000000001 ffff880061099f60 0000000000000498 ffff880061099f68
Call Trace:
[<ffffffff8101cb52>] kvm_vcpu_ioctl+0x1e2/0xd00
arch/x86/kvm/../../../virt/kvm/kvm_main.c:2526
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffffffff817b36b1>] do_vfs_ioctl+0x681/0xe40 fs/ioctl.c:607
[< inline >] SYSC_ioctl fs/ioctl.c:622
[<ffffffff817b3eff>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:613
[<ffffffff85e745b6>] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
Code: 85 2d 20 00 00 4d 8b a4 24 60 03 00 00 e8 c8 8b 50 00 49 8d bc
24 f0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 f3 1f 00 00 4d 8b a4 24 f0 00 00 00 41 83 e4
RIP [< inline >] constant_test_bit ./arch/x86/include/asm/bitops.h:311
RIP [< inline >] kvm_lapic_latched_init arch/x86/kvm/lapic.h:164
RIP [< inline >] kvm_vcpu_ioctl_x86_get_vcpu_events
arch/x86/kvm/x86.c:2936
RIP [<ffffffff81057171>] kvm_arch_vcpu_ioctl+0xa31/0x2ef0
arch/x86/kvm/x86.c:3347
RSP <ffff880062e37900>
---[ end trace 16449377928e034b ]---


or:

kasan: GPF could be caused by NULL-ptr deref or user memory
accessgeneral protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 0 PID: 9555 Comm: syz-executor Not tainted 4.4.0-rc8+ #217
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff88006301de00 ti: ffff880062568000 task.ti: ffff880062568000
RIP: 0010:[<ffffffff810cf5ab>] [<ffffffff810cf5ab>]
wait_lapic_expire+0x6b/0x560
RSP: 0018:ffff88006256fa48 EFLAGS: 00010006
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff88006301e5c8
RDX: 0000000000000011 RSI: 0000000000000000 RDI: ffff880033590360
RBP: ffff88006256fa88 R08: 0000000000000001 R09: 0000000000000002
R10: 0000000000000001 R11: 0000000000000001 R12: ffff880033590000
R13: ffff880033590030 R14: 0000000000000088 R15: ffff88003359002c
FS: 00007f4809354700(0000) GS:ffff88003ec00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4808b53000 CR3: 0000000033f3f000 CR4: 00000000000026f0
Stack:
ffff88006256fa70 0000000000000082 0000000000000003 ffff88006301de00
ffff880033590030 ffff880033590030 ffff880033590000 ffff88003359002c
ffff88006256fc10 ffffffff8106a1dc ffffffff8106a75b 0000000000013210
Call Trace:
[< inline >] vcpu_enter_guest arch/x86/kvm/x86.c:6523
[< inline >] vcpu_run arch/x86/kvm/x86.c:6660
[<ffffffff8106a1dc>] kvm_arch_vcpu_ioctl_run+0x25ec/0x5820
arch/x86/kvm/x86.c:6818
[<ffffffff8101cf61>] kvm_vcpu_ioctl+0x5f1/0xd00
arch/x86/kvm/../../../virt/kvm/kvm_main.c:2375
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffffffff817b36b1>] do_vfs_ioctl+0x681/0xe40 fs/ioctl.c:607
[< inline >] SYSC_ioctl fs/ioctl.c:622
[<ffffffff817b3eff>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:613
[<ffffffff85e745b6>] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
Code: 60 03 00 00 0f 1f 44 00 00 e8 92 07 49 00 4c 8d b3 88 00 00 00
e8 86 07 49 00 4c 89 f2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
3c 02 00 0f 85 d8 04 00 00 4c 8b ab 88 00 00 00 4d 85 ed 75
RIP [<ffffffff810cf5ab>] wait_lapic_expire+0x6b/0x560 arch/x86/kvm/lapic.c:1245
RSP <ffff88006256fa48>
---[ end trace 560c2b85e36670bc ]---

or:

kasan: GPF could be caused by NULL-ptr deref or user memory
accessgeneral protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 3 PID: 11264 Comm: syz-executor Not tainted 4.4.0-rc8+ #217
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880064d55e00 ti: ffff880064dc0000 task.ti: ffff880064dc0000
RIP: 0010:[<ffffffff810d138d>] [<ffffffff810d138d>]
apic_has_pending_timer+0x7d/0x210
RSP: 0018:ffff880064dc7a60 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000004
RDX: 0000000000000017 RSI: 0000000000000000 RDI: 00000000000000b8
RBP: ffff880064dc7a70 R08: 0000000000000002 R09: 0000000000000001
R10: ffff880064d55e00 R11: ffff880063528220 R12: ffff880063250030
R13: ffff880063250030 R14: ffff880063250000 R15: 0000000000000000
FS: 00007fb05f305700(0000) GS:ffff88006d700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000006d7760 CR3: 0000000065ae9000 CR4: 00000000000026e0
Stack:
ffff880063250000 ffff880063250030 ffff880064dc7a88 ffffffff810c7af5
ffffffff86fee5c0 ffff880064dc7c10 ffffffff810685d4 ffffffff8106a75b
0000000000013210 ffff880065a35000 1ffff1000c9b8f59 ffff880064dc0008
Call Trace:
[<ffffffff810c7af5>] kvm_cpu_has_pending_timer+0x15/0x20 arch/x86/kvm/irq.c:36
[< inline >] vcpu_run arch/x86/kvm/x86.c:6669
[<ffffffff810685d4>] kvm_arch_vcpu_ioctl_run+0x9e4/0x5820
arch/x86/kvm/x86.c:6818
[<ffffffff8101cf61>] kvm_vcpu_ioctl+0x5f1/0xd00
arch/x86/kvm/../../../virt/kvm/kvm_main.c:2375
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffffffff817b36b1>] do_vfs_ioctl+0x681/0xe40 fs/ioctl.c:607
[< inline >] SYSC_ioctl fs/ioctl.c:622
[<ffffffff817b3eff>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:613
[<ffffffff85e745b6>] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
Code: ba e9 48 00 0f 1f 44 00 00 e8 b0 e9 48 00 e8 ab e9 48 00 48 8d
bb b8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 46 01 00 00 4c 8b a3 b8 00 00 00 48 b8 00 00
RIP [< inline >] arch_static_branch
./arch/x86/include/asm/jump_label.h:21
RIP [< inline >] static_key_false include/linux/jump_label.h:133
RIP [< inline >] kvm_apic_hw_enabled arch/x86/kvm/lapic.h:117
RIP [< inline >] apic_enabled arch/x86/kvm/lapic.c:121
RIP [<ffffffff810d138d>] apic_has_pending_timer+0x7d/0x210
arch/x86/kvm/lapic.c:1731
RSP <ffff880064dc7a60>
---[ end trace fe9c10b88e48c946 ]---


All crashes suggest that apic is NULL.

On commit b06f3a168cdcd80026276898fd1fee443ef25743 (Jan 6).

[Dmitry Vyukov]

+ more kvm people

[Jeff Merkey]

Dmitry,

You need to check your test harness and add checks for which CPL the
kernel is running at for these GPF faults and add that to your report.
I realize that there are a lot of kernel subsystems which are coded
very loose on checking for this stuff. I have looked through some of
these hangs you reported and I think one of them is related to a
swapgs instruction getting nested, and two others related to code
touching hardware.

Can you figure out how to send the info as to what privilege level you
are at when these faults occur? This one looks like swapgs got nested
and gs was pointing off to oblivion.

:-)

Jeff

[Dmitry Vyukov]

The program opens /dev/kvm under root because it is mounted as 700.
But then do ioctl's under user nobody.
Does it make sense to add UID to kernel BUG/WARNING (at least
capable(CAP_SYS_ADMIN) flag)? Because it's a pretty generic concern
for all crashes.

[Jeff Merkey]

Well !!(cs & 3) is a good clue. According to CS (at least what this
says) we are at ring 0 on this one with gs not set.

Jeff

[Xiao Guangrong]

Hi Dmitry,

Thanks for your report. What's the qemu parameters you are using so that
i can reproduce it locally?

Thanks!

[Dmitry Vyukov]

On Mon, Jan 18, 2016 at 10:57 AM, Xiao Guangrong
<guangro...@linux.intel.com> wrote:
>
> Hi Dmitry,
>
> Thanks for your report. What's the qemu parameters you are using so that
> i can reproduce it locally?
>
> Thanks!

I've attached my config.
I start qemu as:
qemu-system-x86_64 -hda wheezy.img -net
user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic -nographic -kernel
arch/x86/boot/bzImage -append "console=ttyS0 root=/dev/sda debug
earlyprintk=serial slub_debug=UZ" -enable-kvm -m 2G -numa
node,nodeid=0,cpus=0-1 -numa node,nodeid=1,cpus=2-3 -smp
sockets=2,cores=2,threads=1 -usb -usbdevice mouse -usbdevice tablet
-soundhw all

[Paolo Bonzini]

On 08/01/2016 19:42, Dmitry Vyukov wrote:
> Hello,
>
> The following program triggers GPF in kvm_lapic_latched_init if run in
> a parallel loop:
> https://gist.githubusercontent.com/dvyukov/524b398f379440b21115/raw/9627095f57a72501fb51bf7565471d31732beeee/gistfile1.txt

I've noticed that the program here tends to segfault a lot, even before
reaching the kernel. Is this intended?

Thanks,

Paolo

[Dmitry Vyukov]

Yes.

[Dmitry Vyukov]

Ping. Just hit it again on 67016f6cdfd079e632bbc49e33178b2d558c120a (Jun 20):

general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:

CPU: 1 PID: 12583 Comm: syz-executor Not tainted 4.7.0-rc4+ #2

Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011

task: ffff8800355d46c0 ti: ffff880034198000 task.ti: ffff880034198000
RIP: 0010:[<ffffffff811260ba>] [<ffffffff811260ba>]
wait_lapic_expire+0x6a/0x5e0
RSP: 0018:ffff88003419fa40 EFLAGS: 00010002
RAX: dffffc0000000000 RBX: ffff880033cf0040 RCX: ffffc900020e4000
RDX: 0000000000000010 RSI: 1ffff10006833001 RDI: ffff880033cf03a0
RBP: ffff88003419fa78 R08: 0000000000000001 R09: 0000000000000002
R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000
R13: ffff880033cf0070 R14: 0000000000000080 R15: ffff880033cf0040
FS: 00007fd1bdd14700(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000

CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00007fd1bdcf3000 CR3: 0000000061716000 CR4: 00000000000026e0
Stack:
0000000000000086 0000000000000003 ffff880033cf0070 00000000ffffffff
ffff880033cf0070 ffff880033cf006c ffff880033cf0040 ffff88003419fc10
ffffffff810bee70 ffffffff810bf48f ffffffff81478fa0 ffff8800355d46c0
Call Trace:
[< inline >] vcpu_enter_guest arch/x86/kvm/x86.c:6638
[< inline >] vcpu_run arch/x86/kvm/x86.c:6777
[<ffffffff810bee70>] kvm_arch_vcpu_ioctl_run+0x2490/0x5f60
arch/x86/kvm/x86.c:6935
[<ffffffff8106841e>] kvm_vcpu_ioctl+0x61e/0xe70
arch/x86/kvm/../../../virt/kvm/kvm_main.c:2457
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffffffff818510bc>] do_vfs_ioctl+0x18c/0xff0 fs/ioctl.c:674
[< inline >] SYSC_ioctl fs/ioctl.c:689
[<ffffffff81851faf>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
[<ffffffff86a97000>] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207
Code: 03 00 00 0f 1f 44 00 00 e8 54 04 47 00 4d 8d b4 24 80 00 00 00
e8 47 04 47 00 4c 89 f2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80>
3c 02 00 0f 85 58 05 00 00 4d 8b ac 24 80 00 00 00 4d 85 ed
RIP [<ffffffff811260ba>] wait_lapic_expire+0x6a/0x5e0 arch/x86/kvm/lapic.c:1300
RSP <ffff88003419fa40>
---[ end trace dc1986f78b27e282 ]---

[Paolo Bonzini]

On 22/06/2016 10:20, Dmitry Vyukov wrote:
>>> >> All crashes suggest that apic is NULL.
>>> >>
>>> >> On commit b06f3a168cdcd80026276898fd1fee443ef25743 (Jan 6).
>
> Ping. Just hit it again on 67016f6cdfd079e632bbc49e33178b2d558c120a (Jun 20):

This might have been the same bug you reported yesterday in kvm_set_cr8.
I've sent a patch to fix static keys.

Paolo

[Dmitry Vyukov]

Then it is probably the same as the following one as well?

WARNING: CPU: 3 PID: 23379 at kernel/sched/core.c:2583[< none
>] preempt_notifier_register+0x2b/0x120 kernel/sched/core.c:2583
registering preempt_notifier while notifiers disabled
Modules linked in:
CPU: 3 PID: 23379 Comm: syz-executor Not tainted 4.7.0-rc4+ #2

Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011

ffffffff880b58e0 ffff88003a79fa60 ffffffff82cc62cf ffffffff81495e98
fffffbfff1016b1c ffff88003a79fad8 0000000000000000 ffffffff86ca0220
ffffffff813ed78b 0000000000000009 ffff88003a79faa8 ffffffff8136d27f
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff82cc62cf>] dump_stack+0x12e/0x18f lib/dump_stack.c:51
[<ffffffff8136d27f>] __warn+0x19f/0x1e0 kernel/panic.c:516
[<ffffffff8136d36c>] warn_slowpath_fmt+0xac/0xd0 kernel/panic.c:531
[<ffffffff813ed78b>] preempt_notifier_register+0x2b/0x120
kernel/sched/core.c:2583
[<ffffffff81067d96>] vcpu_load+0x46/0x70
arch/x86/kvm/../../../virt/kvm/kvm_main.c:146
[<ffffffff810b933f>] kvm_arch_vcpu_setup+0x1f/0x60 arch/x86/kvm/x86.c:7390
[< inline >] kvm_vm_ioctl_create_vcpu
arch/x86/kvm/../../../virt/kvm/kvm_main.c:2355
[<ffffffff8106b9f2>] kvm_vm_ioctl+0x582/0x10d0
arch/x86/kvm/../../../virt/kvm/kvm_main.c:2839

[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffffffff818510bc>] do_vfs_ioctl+0x18c/0xff0 fs/ioctl.c:674
[< inline >] SYSC_ioctl fs/ioctl.c:689
[<ffffffff81851faf>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:680
[<ffffffff86a97000>] entry_SYSCALL_64_fastpath+0x23/0xc1
arch/x86/entry/entry_64.S:207

---[ end trace c0e5c1ad551a4947 ]---

[Paolo Bonzini]

On 22/06/2016 10:38, Dmitry Vyukov wrote:
> On Wed, Jun 22, 2016 at 10:36 AM, Paolo Bonzini <pbon...@redhat.com> wrote:
>> On 22/06/2016 10:20, Dmitry Vyukov wrote:
>>>>>>> All crashes suggest that apic is NULL.
>>>>>>>
>>>>>>> On commit b06f3a168cdcd80026276898fd1fee443ef25743 (Jan 6).
>>>
>>> Ping. Just hit it again on 67016f6cdfd079e632bbc49e33178b2d558c120a (Jun 20):
>>
>> This might have been the same bug you reported yesterday in kvm_set_cr8.
>> I've sent a patch to fix static keys.
>
> Then it is probably the same as the following one as well?

Not 100% sure, can you send the reproducer?

Paolo

> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

[Dmitry Vyukov]

On Wed, Jun 22, 2016 at 10:46 AM, Paolo Bonzini <pbon...@redhat.com> wrote:
>
>
> On 22/06/2016 10:38, Dmitry Vyukov wrote:
>> On Wed, Jun 22, 2016 at 10:36 AM, Paolo Bonzini <pbon...@redhat.com> wrote:
>>> On 22/06/2016 10:20, Dmitry Vyukov wrote:
>>>>>>>> All crashes suggest that apic is NULL.
>>>>>>>>
>>>>>>>> On commit b06f3a168cdcd80026276898fd1fee443ef25743 (Jan 6).
>>>>
>>>> Ping. Just hit it again on 67016f6cdfd079e632bbc49e33178b2d558c120a (Jun 20):
>>>
>>> This might have been the same bug you reported yesterday in kvm_set_cr8.
>>> I've sent a patch to fix static keys.
>>
>> Then it is probably the same as the following one as well?
>
> Not 100% sure, can you send the reproducer?

I can't directly reproduce this. When I tried I hit other known bugs, e.g.:

BUG: KASAN: use-after-free in do_raw_spin_lock+0x281/0x2b0 at addr
ffff8800606e0c64
Read of size 4 by task syz-executor/11240
page:ffffea000181b800 count:0 mapcount:-127 mapping: (null) index:0x0
flags: 0x4fffe0000000000()
page dumped because: kasan: bad access detected
CPU: 2 PID: 11240 Comm: syz-executor Tainted: G D 4.7.0-rc4+ #2

Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011

ffffffff880b58e0 ffff88004082f850 ffffffff82cc62cf ffffffff4082f8e0
fffffbfff1016b1c ffff88004082f8e0 ffff8800606e0c64 ffff8800606e0c98
ffff88006b31d6a8 ffff8800606e0c60 ffff88004082f8d0 ffffffff817bdfb2

Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff82cc62cf>] dump_stack+0x12e/0x18f lib/dump_stack.c:51

[< inline >] print_address_description mm/kasan/report.c:191
[<ffffffff817bdfb2>] kasan_report_error+0x4e2/0x510 mm/kasan/report.c:276
[< inline >] kasan_report mm/kasan/report.c:298
[<ffffffff817be09e>] __asan_report_load4_noabort+0x3e/0x40
mm/kasan/report.c:318
[< inline >] debug_spin_lock_before kernel/locking/spinlock_debug.c:83
[<ffffffff81484e81>] do_raw_spin_lock+0x281/0x2b0
kernel/locking/spinlock_debug.c:135
[< inline >] __raw_spin_lock_irq include/linux/spinlock_api_smp.h:131
[<ffffffff86a969ff>] _raw_spin_lock_irq+0x6f/0x80 kernel/locking/spinlock.c:167
[< inline >] spin_lock_irq include/linux/spinlock.h:332
[<ffffffff81073eff>] kvm_irqfd_release+0x2f/0x120
arch/x86/kvm/../../../virt/kvm/eventfd.c:584
[<ffffffff8105dfca>] kvm_vm_release+0x3a/0x50
arch/x86/kvm/../../../virt/kvm/kvm_main.c:752
[<ffffffff81819ee6>] __fput+0x236/0x780 fs/file_table.c:208
[<ffffffff8181a4b5>] ____fput+0x15/0x20 fs/file_table.c:244
[<ffffffff813d0826>] task_work_run+0xf6/0x170 kernel/task_work.c:115
[< inline >] exit_task_work include/linux/task_work.h:21
[<ffffffff8137aed2>] do_exit+0xa62/0x2c80 kernel/exit.c:748
[<ffffffff8137d268>] do_group_exit+0x108/0x330 kernel/exit.c:878
[<ffffffff813a0734>] get_signal+0x634/0x15e0 kernel/signal.c:2307
[<ffffffff811fa943>] do_signal+0x83/0x1f20 arch/x86/kernel/signal.c:783
[<ffffffff81006695>] exit_to_usermode_loop+0x1a5/0x210
arch/x86/entry/common.c:229
[< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:264
[<ffffffff8100885f>] syscall_return_slowpath+0x2bf/0x340
arch/x86/entry/common.c:329
[<ffffffff86a9709c>] entry_SYSCALL_64_fastpath+0xbf/0xc1
arch/x86/entry/entry_64.S:241


So probably it's induced by other bugs.


I've looked at preempt_notifier_inc/preempt_notifier_dec calls, but I
don't see any obvious bugs. I thought that maybe preempt_notifier_inc
is called after installing fd into the file table, in which case
another thread could do ioctl's on the fd before preempt_notifier_inc,
but it does not seem to be the case. dup calls should also be properly
handled, right?