lkml.org 
[lkml]   [2022]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: data-race in vmci_ctx_dequeue_datagram / vmci_ctx_rcv_notifications_release
On Fri, Aug 19, 2022 at 06:33:00AM -0400, Abhishek Shah wrote:
> Hi all,
>
> We found the following race involving the *context->notify* variable. We
> were unable to find any security implications of the race, but we would
> still like to report it. Please let us know what you think.
>
> Thanks!
>
>
> *-----------------Report--------------*
>
> *write* to 0xffffffff8832e400 of 1 bytes by task 6542 on cpu 0:
> ctx_clear_notify drivers/misc/vmw_vmci/vmci_context.c:51 [inline]
> ctx_clear_notify_call drivers/misc/vmw_vmci/vmci_context.c:62 [inline]
> vmci_ctx_rcv_notifications_release+0x26a/0x280
> drivers/misc/vmw_vmci/vmci_context.c:926
> vmci_host_do_recv_notifications drivers/misc/vmw_vmci/vmci_host.c:900
> [inline]
> vmci_host_unlocked_ioctl+0x17cf/0x1800
> drivers/misc/vmw_vmci/vmci_host.c:949
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:870 [inline]
> __se_sys_ioctl+0xe1/0x150 fs/ioctl.c:856
> __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:856
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x44/0xae
>
> *write* to 0xffffffff8832e400 of 1 bytes by task 6541 on cpu 1:
> ctx_clear_notify drivers/misc/vmw_vmci/vmci_context.c:51 [inline]
> ctx_clear_notify_call drivers/misc/vmw_vmci/vmci_context.c:62 [inline]
> vmci_ctx_dequeue_datagram+0x1fc/0x2c0
> drivers/misc/vmw_vmci/vmci_context.c:519
> vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:426
> [inline]
> vmci_host_unlocked_ioctl+0x91a/0x1800 drivers/misc/vmw_vmci/vmci_host.c:925
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:870 [inline]
> __se_sys_ioctl+0xe1/0x150 fs/ioctl.c:856
> __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:856
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x44/0xae
>
> Reported by Kernel Concurrency Sanitizer on:
> CPU: 1 PID: 6541 Comm: syz-executor2-n Not tainted 5.18.0-rc5+ #107
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
> 04/01/2014
>
> Input CPU 0:
> r0 = openat$vmci(0xffffff9c, &(0x7f0000001440)='/dev/vmci\x00', 0x2, 0x0)
> ioctl$IOCTL_VMCI_VERSION2(r0, 0x7a7, &(0x7f0000000000)=0xb0000)
> ioctl$IOCTL_VMCI_INIT_CONTEXT(r0, 0x7a0, &(0x7f0000000040)={@my=0x1})
> ioctl$IOCTL_VMCI_NOTIFICATIONS_RECEIVE(r0, 0x7a6, &(0x7f0000000080)={0x0,
> 0x0, 0x101, 0x5})
>
> Input CPU 1:
> r0 = openat$vmci(0xffffff9c, &(0x7f0000001440)='/dev/vmci\x00', 0x2, 0x0)
> ioctl$IOCTL_VMCI_VERSION2(r0, 0x7a7, &(0x7f0000000000)=0xb0000)
> ioctl$IOCTL_VMCI_INIT_CONTEXT(r0, 0x7a0, &(0x7f0000000040)={@my=0x1})
> ioctl$IOCTL_VMCI_DATAGRAM_RECEIVE(r0, 0x7ac, &(0x7f00000004c0)={0x0})


If multiple userspace programs open this, then yes, there will be
oddities, but that shouldn't be an issue, right?

Do you have a proposed patch for this to show what you think should be
done?

thanks,

greg k-h

\
 
 \ /
  Last update: 2022-08-19 12:57    [W:0.025 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site