linux-kernel - Re: [syzbot] [kvm?] possible deadlock in kvm_arch_pm

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: <Z31FmKRs73jh44Q9@google.com>
Date: Tue, 7 Jan 2025 07:18:50 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: syzbot <syzbot+352e553a86e0d75f5120@...kaller.appspotmail.com>
Cc: bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com, 
	kvm@...r.kernel.org, linux-kernel@...r.kernel.org, mingo@...hat.com, 
	pbonzini@...hat.com, syzkaller-bugs@...glegroups.com, tglx@...utronix.de, 
	x86@...nel.org
Subject: Re: [syzbot] [kvm?] possible deadlock in kvm_arch_pm_notifier

On Mon, Jan 06, 2025, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    0bc21e701a6f MAINTAINERS: Remove Olof from SoC maintainers
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=163abd0f980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=86dd15278dbfe19f
> dashboard link: https://syzkaller.appspot.com/bug?extid=352e553a86e0d75f5120
> compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> userspace arch: i386
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> Downloadable assets:
> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/7feb34a89c2a/non_bootable_disk-0bc21e70.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/7552d06d3231/vmlinux-0bc21e70.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/0d1494ecdf2f/bzImage-0bc21e70.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+352e553a86e0d75f5120@...kaller.appspotmail.com
> 
> ======================================================
> WARNING: possible circular locking dependency detected
> 6.13.0-rc5-syzkaller-00012-g0bc21e701a6f #0 Not tainted
> ------------------------------------------------------
> syz.8.2149/14842 is trying to acquire lock:
> ffffc90006bccb58 (&kvm->lock){+.+.}-{4:4}, at: kvm_arch_suspend_notifier arch/x86/kvm/x86.c:6919 [inline]
> ffffc90006bccb58 (&kvm->lock){+.+.}-{4:4}, at: kvm_arch_pm_notifier+0xf5/0x2b0 arch/x86/kvm/x86.c:6941
> 
> but task is already holding lock:
> ffffffff8dcbeb10 ((pm_chain_head).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain_robust kernel/notifier.c:344 [inline]
> ffffffff8dcbeb10 ((pm_chain_head).rwsem){++++}-{4:4}, at: blocking_notifier_call_chain_robust+0xa9/0x170 kernel/notifier.c:333
> 
> which lock already depends on the new lock.

Huh.  I was going to say that this is essentially the same underlying problem
that led to commit 44d174596260 ("KVM: Use dedicated mutex to protect
kvm_usage_count to avoid deadlock"), where taking kvm_lock in notifier callbacks
is prone to deadlocks that are all but impossible to hit in practice.

But this is the per-VM lock, kvm->lock, not the global lock.  I don't see any
reason to take kvm->lock in kvm_arch_suspend_notifier().  vcpu->arch.pv_time.active
and vcpu->arch.pvclock_set_guest_stopped_request are protected by vcpu->mutex,
not kvm->lock, i.e. accessing those fields is racy no matter what.