linux-cve-announce - CVE-2022-50081: KVM: Unconditionally get a ref to /dev/kvm module when creating a VM

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

Message-ID: <2025061857-CVE-2022-50081-80dc@gregkh>
Date: Wed, 18 Jun 2025 13:02:26 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-50081: KVM: Unconditionally get a ref to /dev/kvm module when creating a VM

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

KVM: Unconditionally get a ref to /dev/kvm module when creating a VM

Unconditionally get a reference to the /dev/kvm module when creating a VM
instead of using try_get_module(), which will fail if the module is in
the process of being forcefully unloaded.  The error handling when
try_get_module() fails doesn't properly unwind all that has been done,
e.g. doesn't call kvm_arch_pre_destroy_vm() and doesn't remove the VM
from the global list.  Not removing VMs from the global list tends to be
fatal, e.g. leads to use-after-free explosions.

The obvious alternative would be to add proper unwinding, but the
justification for using try_get_module(), "rmmod --wait", is completely
bogus as support for "rmmod --wait", i.e. delete_module() without
O_NONBLOCK, was removed by commit 3f2b9c9cdf38 ("module: remove rmmod
--wait option.") nearly a decade ago.

It's still possible for try_get_module() to fail due to the module dying
(more like being killed), as the module will be tagged MODULE_STATE_GOING
by "rmmod --force", i.e. delete_module(..., O_TRUNC), but playing nice
with forced unloading is an exercise in futility and gives a falsea sense
of security.  Using try_get_module() only prevents acquiring _new_
references, it doesn't magically put the references held by other VMs,
and forced unloading doesn't wait, i.e. "rmmod --force" on KVM is all but
guaranteed to cause spectacular fireworks; the window where KVM will fail
try_get_module() is tiny compared to the window where KVM is building and
running the VM with an elevated module refcount.

Addressing KVM's inability to play nice with "rmmod --force" is firmly
out-of-scope.  Forcefully unloading any module taints kernel (for obvious
reasons)  _and_ requires the kernel to be built with
CONFIG_MODULE_FORCE_UNLOAD=y, which is off by default and comes with the
amusing disclaimer that it's "mainly for kernel developers and desperate
users".  In other words, KVM is free to scoff at bug reports due to using
"rmmod --force" while VMs may be running.

The Linux kernel CVE team has assigned CVE-2022-50081 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 5.15.33 with commit 43637ee17092eef0b97a327bb4355230060431c4 and fixed in 5.15.63 with commit 177bf354200962c6f0de6dd37c86a9bf3b54003a
	Issue introduced in 5.18 with commit 5f6de5cbebee925a612856fce6f9182bb3eee0db and fixed in 5.19.4 with commit 865e08b77c244eed0b80439320e7e8440f61ebce
	Issue introduced in 5.18 with commit 5f6de5cbebee925a612856fce6f9182bb3eee0db and fixed in 6.0 with commit 405294f29faee5de8c10cb9d4a90e229c2835279
	Issue introduced in 4.9.311 with commit 6e84a56ce3215f078e9a70e309d602a961806aca
	Issue introduced in 4.14.276 with commit c1dd3547c191dc9724884cbc37432af2df382702
	Issue introduced in 4.19.238 with commit c7e4e89455fceb2002269402b9335a185e9db2e6
	Issue introduced in 5.4.189 with commit a1c03f11cc3c703fa39691d2dab98a5f5543326c
	Issue introduced in 5.10.110 with commit eccfee44949d2d8ac9675d5b3f29cacaed5ba6c8
	Issue introduced in 5.16.19 with commit 2ec90e21f1c0cd2b71014c96474e003b029c457f
	Issue introduced in 5.17.2 with commit 9b709d19bb34955de210f1fc2e71d7c9a961f3c1

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-50081
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	virt/kvm/kvm_main.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/177bf354200962c6f0de6dd37c86a9bf3b54003a
	https://git.kernel.org/stable/c/865e08b77c244eed0b80439320e7e8440f61ebce
	https://git.kernel.org/stable/c/405294f29faee5de8c10cb9d4a90e229c2835279