[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <b876424f-3364-4348-a20a-5ff271806452@suse.com>
Date: Sat, 17 May 2025 07:26:58 +0200
From: Juergen Gross <jgross@...e.com>
To: cve@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: CVE-2022-49933: KVM: VMX: Reset eVMCS controls in VP assist page
during hardware disabling
On 02.05.25 17:54, Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman <gregkh@...nel.org>
>
> Description
> ===========
>
> In the Linux kernel, the following vulnerability has been resolved:
>
> KVM: VMX: Reset eVMCS controls in VP assist page during hardware disabling
>
> Reset the eVMCS controls in the per-CPU VP assist page during hardware
> disabling instead of waiting until kvm-intel's module exit. The controls
> are activated if and only if KVM creates a VM, i.e. don't need to be
> reset if hardware is never enabled.
>
> Doing the reset during hardware disabling will naturally fix a potential
> NULL pointer deref bug once KVM disables CPU hotplug while enabling and
> disabling hardware (which is necessary to fix a variety of bugs). If the
> kernel is running as the root partition, the VP assist page is unmapped
> during CPU hot unplug, and so KVM's clearing of the eVMCS controls needs
> to occur with CPU hot(un)plug disabled, otherwise KVM could attempt to
> write to a CPU's VP assist page after it's unmapped.
>
> The Linux kernel CVE team has assigned CVE-2022-49933 to this issue.
Is this really a security issue?
I don't see how an unprivileged user could trigger the mentioned NULL deref,
as it requires CPU hotunplug (can't be triggered by user) to happen in parallel
with unloading the kvm module (can't be triggered by user either).
Juergen
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3684 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists