linux-kernel - Re: [BUG?] KVM: Unexpected KVM_CREATE

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] [day] [month] [year] [list]

Message-ID: <CANypQFY74VSbx+F0oGpy+NB0+_NUm3vVJen4BmaL_F6ez73vDg@mail.gmail.com>
Date: Wed, 27 Aug 2025 20:54:39 +0800
From: Jiaming Zhang <r772577952@...il.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, Sean Christopherson <seanjc@...gle.com>, linux-kernel@...r.kernel.org, 
	syzkaller@...glegroups.com
Subject: Re: [BUG?] KVM: Unexpected KVM_CREATE_VCPU failure with EBADF

Hi Paolo,

Thank you very much for the analysis. You were spot on.

Your suspicion about a race condition in the test executor was
correct. I confirmed this by modifying the reproducer: after
increasing the timeout in the main thread's wait loop before
close_fds() is called, the EBADF error disappeared. This confirms the
issue was indeed caused by faulty synchronization in the test harness.
I apologize for any noise this report may have caused.

Thanks again for your time and expertise. It's much appreciated.

Best regards,
Jiaming Zhang


Paolo Bonzini <pbonzini@...hat.com> 于2025年8月27日周三 17:46写道：
>
> I have occasionally seen EINVAL and EEXIST as well. My suspicion is a
> race condition due to incorrect synchronization of the executor
> threads with close_fds():
>
> 1) the failing executor thread calls KVM_CREATE_VM
> 2) the main thread calls close_fds() while the failing thread is still
> running, and closes the vm file descriptor
> 3) the failing thread then gets EBADF.
>
> For example, EEXIST could happen if before step 3, another executor
> thread calls KVM_CREATE_VM, receiving the same file descriptor, and
> manages to call KVM_CREATE_VCPU(0) before the failing thread.
>
> I attach a simplified reproducer.
>
> Paolo
>
> On Wed, Aug 27, 2025 at 10:57 AM Jiaming Zhang <r772577952@...il.com> wrote:
> >
> > Hello KVM maintainers and developers,
> >
> > We are writing to report a potential bug discovered in the KVM
> > subsystem with our modified syzkaller. The issue is that a
> > KVM_CREATE_VCPU ioctl call can fail with EBADF on a valid VM file
> > descriptor.
> >
> > The attached C program (repro.c) sets up a high-concurrency
> > environment by forking multiple processes, each running the test logic
> > in a loop. In the core test function (syz_func), it sequentially
> > creates two VMs and then attempts to create one VCPU for each.
> > Intermittently, one of the two KVM_CREATE_VCPU calls fails, returning
> > -1 and setting errno to 9 (EBADF).
> >
> > The VM file descriptor (vm_fd1/vm_fd2) passed to KVM_CREATE_VCPU was
> > just successfully returned by a KVM_CREATE_VM ioctl within the same
> > thread. An EBADF error in this context is unexpected. In addition, the
> > threading model of test code ensures that the creation and use of
> > these file descriptors happen sequentially within a single thread,
> > ruling out a user-space race condition where another thread could have
> > closed the file descriptor prematurely.
> >
> > This issue was first found on v6.1.147 (commit
> > 3594f306da129190de25938b823f353ef7f9e322), and is still reproducible
> > on the latest version (v6.17-rc3, commit
> > 1b237f190eb3d36f52dffe07a40b5eb210280e00).
> >
> > Other environmental information:
> > - Architecture: x86_64
> > - Distribution: Ubuntu 22.04
> >
> > The complete C code that triggers this issue and the .config file used
> > for Linux Kernel v6.1.147 and v6.17-rc3 compilation are attached.
> >
> > Thank you for your time and for your incredible work on KVM. We hope
> > this report is helpful. Please let me know if any further information
> > is required.
> >
> > Best regards,
> > Jiaming Zhang