[CVE-2022-49932][MODERATE REGULAR] KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace [ Upstream

[AL-KERNEL <alkernel@kernelcve.org>]

CVE: CVE-2022-49932
Priority: MODERATE REGULAR
AL-KERNEL base severity: MODERATE
KPANIC flag: NO
Patch: KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace [ Upstream
Commit: e136e969d268b9b89329c816c002e53f60e82985
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e136e969d268b9b89329c816c002e53f60e82985
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2022-49932
Analysis date: Mon, 12 Oct 2026 21:19:11 -0400
ActionableScore: 1
ActionableScore lower bound: unknown
Actionable bucket: Ordinary Moderate
Manual review required: NO

Summary:
No one-sentence report phrase was found.

======================================================================
ABOUT THIS REPORT
======================================================================

The original Linux kernel CVE announcement for CVE-2022-49932 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2022-49932

The original announcement does not normally provide a security severity
estimate, CVSS assessment, or enough information to determine whether the
reported kernel bug represents a practically relevant security issue.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin. It combines
an autonomous classifier with LLM-assisted technical analysis and a
separate ActionableScore mechanism.

The purpose of this report is to prioritize Linux kernel CVEs before
manual review, identify cases that require prompt investigation, and
support automatic closure of issues that are unlikely to have meaningful
security impact.

Published priority for this report: MODERATE REGULAR
Manual review required: NO

A detailed explanation of the methodology and priority rules is included
at the end of this message.

======================================================================
AL-KERNEL CLASSIFICATION RESULT
======================================================================

CVE-2022-49932	MODERATE	https://www.kernelcve.org/list/?q=CVE-2022-49932 CHECK WITH IMPACT FROM ORIG NN MODERATE | AEGIS IMPACT MODERATE_KPANIC AEGIS_AS=0 LEGACY=MODERATE RESULT=DIFF (independent Legacy and Aegis differ; FINAL: MODERATE, Aegis: MODERATE_KPANIC)	Maybe valid. Check manually. Hints by AL-KERNEL: The best (paranoid) CVSS is 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H';CWE-362;CWE-665;**CWE-476;Other CVSS 'AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L';BEST CVSS score: '4.7';DESCR 'A local initialization race exists because dev kvm can become available before all VMX resources are initialized. A process with access to dev kvm can create a VM and vCPU during this narrow module loading window, causing vmx_vcpu_load_vmcs to use an uninitialized per CPU loaded VMCS list and trigger a NULL pointer dereference. For the CVSS the PR:L reflects that the attacker needs local execution and permission to access dev kvm, but does not need full administrative privileges. AC:H applies because successful triggering depends on racing VM creation against kvm_intel module initialization. The demonstrated impact is a kernel Oops and denial of service. Availability may become high when panic_on_oops is enabled or when the fault destabilizes KVM workloads. The analyzed write targets a fixed address near NULL and does not provide evidence of UAF, OOB access, information disclosure, arbitrary write, or privilege escalation.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Ordinary Moderate (with actual score 1)	MAYBE	NULLPTR VIRT INIT HARDWARE CVEOUTDATED  DECREASED_TO_MODERATE_REGULAR_FROM_MODERATE7_BASED_ON_GUESSCVSS_AND_CIANNH	-	-	checked

======================================================================
ACTIONABLESCORE ANALYSIS
======================================================================

ActionableScore=1
PrimitiveClass=CLASS_C
RealUAF=NO
HostAdminRequired=NO
NamespaceScopedPrivilege=NO
ImportantCandidate=NO
ManualReview=RECOMMENDED
AutoDowngradeAllowed=YES
RequiresHostUID0=NO
AuthorizationDecisionBypass=NO
ProtectedResourceImpact=NONE
B4PendingReview=NO
B4PendingConfirmed=NO

1. ActionableScore

* Raw conservative score: 1
* Conservative score: 1
* Raw paranoid score: 1
* Paranoid score: 1
* No floor or cap was applied.
* Final recommended bucket: **Ordinary Moderate**::

2. Signal breakdown

Positive signals:

* +1 Local below-host-admin trigger. A local process permitted to access `/dev/kvm` can create a VM and vCPU without host-administrator powers.
* +1 Reliable kernel crash or strong DoS. The supplied trace demonstrates a kernel NULL-pointer write fault and Oops in `vmx_vcpu_load_vmcs()`.

Negative signals:

* -1 Hard one-shot initialization race. The ioctl must reach KVM after `/dev/kvm` is exposed but before `vmx_init()` initializes the per-CPU `loaded_vmcss_on_cpu` lists. The attacking process cannot independently extend this narrow module-initialization interval.

Important non-awarded signals:

* No UAF, OOB access, controlled reclaim, repeated release, refcount corruption, or active-state replacement is established.
* The write is directed to a fixed address near NULL through an uninitialized list head. It is not an attacker-directed kernel write.
* No confidentiality, integrity, privilege-escalation, or guest-to-host corruption primitive is demonstrated.
* No extra availability point is awarded for the same Oops.
* No remote reachability is established.
* B5-R does not apply because there is no retry-accumulated heap OOB write.
* B3-PENDING does not apply because there is no shared-backing write.
* B4-PENDING does not apply because no authorization decision changes from DENY to ALLOW.

3. Reachability analysis

The relevant attacker is a local host userspace or VMM process with permission to open `/dev/kvm` and issue VM and vCPU creation ioctls. Such access can be granted below host-admin level, so host UID 0 and host-administrator capabilities are not required for the triggering process.

The trigger is not guest-only because no guest exists until the local VMM creates the VM and vCPU. It is also not a compound guest plus VMM sequence. A separate privileged actor or system mechanism normally initiates or autoloads `kvm_intel`, creating the short vulnerable interval, but the attacker only needs `/dev/kvm` access during that interval.

No namespace-scoped capability supplies the complete trigger. Intel VMX support and loading of `kvm_intel` are prerequisites, but this is common hardware and does not justify a rare-hardware penalty. The race is narrow and tied to one module initialization transition. Repeating it generally requires another module unload and load cycle outside the ordinary attacker permissions.

4. Primitive and severity interpretation

The exact primitive is a write fault through an uninitialized per-CPU list head. `kvm_init()` exposes `/dev/kvm` before VMX-specific initialization completes, allowing vCPU creation to reach `vmx_vcpu_load_vmcs()` before `loaded_vmcss_on_cpu` is configured.

This is invalid-state consumption with a fixed near-NULL destination, classified as CLASS_C. It is neither stale storage nor an active structured-object UAF. There is no first lifetime-ending operation, surviving dangling reference, or second lifetime/refcount mutation.

The demonstrated consequence is a kernel Oops and local denial of service. A host panic is possible under `panic_on_oops`, but that does not create a separate primitive. Arbitrary write, information disclosure, privilege escalation, and guest-to-host escape remain unsupported.

ImportantCandidate is NO because the evidence establishes crash-only behavior without independently useful corruption leverage. AutoDowngradeAllowed is YES because no unresolved Class A or strong Class B primitive would be lost, although manual review remains recommended due to the KVM exposure and timing-sensitive initialization path.

5. One-sentence report phrase

A local process with access to `/dev/kvm` can race VMX module initialization and create a vCPU before per-CPU VMCS lists are initialized, causing a fixed near-NULL write fault and kernel Oops without a demonstrated UAF, arbitrary-write, or privilege-escalation primitive.

6. Manual review recommendation

MANUAL CHECK RECOMMENDED

Confirm the affected product permissions for `/dev/kvm`, module autoload behavior, and whether `panic_on_oops` converts the demonstrated Oops into host-wide failure.

7. Call-site confidence

Call-site confidence: high

======================================================================
UPSTREAM PATCH SUMMARY
======================================================================

Patch: KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace [ Upstream
Commit: e136e969d268b9b89329c816c002e53f60e82985
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e136e969d268b9b89329c816c002e53f60e82985

Changed files:
  arch/x86/kvm/vmx/vmx.c

Diff excerpt:

Not included in this email. See the upstream URL for the full patch.

Full patch:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e136e969d268b9b89329c816c002e53f60e82985

======================================================================
DETAILED REPORT METHODOLOGY
======================================================================

The original Linux kernel CVE announcement for CVE-2022-49932 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2022-49932

The original CVE announcement normally does not include a security-level
estimate. In particular, it may not contain a CVSS assessment, an impact
level, or enough information to determine whether the reported bug is a
practically relevant security issue. One purpose of this parallel CVE list
is to provide that missing technical and prioritization information.

The original goal of the AL-KERNEL project was to prioritize Linux kernel
CVE analysis automatically before manual review. The system can also help
identify non-security issues that may be suitable for automatic closure.

This report was generated by AL-KERNEL, an AI-assisted Linux kernel
vulnerability analysis system developed by Alexander Larkin.

The first analysis stage combines an autonomous classifier with additional
LLM-based analysis. The autonomous classifier runs locally on a CPU and is
based on a backpropagation neural network. Together, these mechanisms
produce a technical vulnerability description, identify likely weakness
types, estimate CVSS severity, and provide input for ActionableScore.

Two CVSS estimates are retained because incomplete kernel vulnerability
information often permits more than one defensible interpretation:

  Conservative CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
  The Best / paranoid CVSS vector: AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
  The Best / paranoid CVSS score: 4.7

The conservative vector represents a lower-impact interpretation.
The Best/paranoid vector intentionally represents a plausible upper-bound
interpretation and should not automatically be treated as demonstrated
real-world impact.

CVSS may also need to be adjusted for a particular Linux deployment,
because actual reachability, privileges, enabled kernel configuration,
hardware, namespaces, exposed device nodes, and other environmental
conditions can differ significantly between systems.

A separate ActionableScore mechanism evaluates practical remediation
urgency. Its analysis may include reachability, attack prerequisites,
subsystem exposure, memory-corruption characteristics, denial-of-service
reliability, and possible confidentiality, integrity, or
privilege-escalation impact.

  Conservative ActionableScore: unknown
  Paranoid ActionableScore: 1

The final base severity is taken directly from the second tab-separated
field of the AL-KERNEL classification result. ActionableScore does not
replace or independently override that final AL-KERNEL decision, and
if ActionableScore adjusted impact level of ALKERNEL, then you would see
self-readable flags above like INCREASED_TO_HIGH_BASED_ON_ACTIONABLESCOREHIGHEREQTHAN7.

For an AL-KERNEL result of MODERATE, this report uses the following
additional presentation split:

  ActionableScore below 5   -> MODERATE REGULAR
  ActionableScore 5 or more -> MODERATE 7.0

The distinction between MODERATE REGULAR and MODERATE 7.0 makes it
possible to identify Moderate issues that should receive manual analysis
and fixes before lower-priority MODERATE REGULAR issues. In many cases,
MODERATE REGULAR fixes may wait for a later rebase or routine update.

There is one override in which MODERATE REGULAR becomes MODERATE 7.0
even when the ActionableScore is below 5. When the AL-KERNEL result
contains the KPANIC flag, a MODERATE result is always presented as
MODERATE 7.0. The KPANIC flag selected with few regexps without
usage of AI at all, so it helps to detect cases when Kernel Crash happens
and similar (to filter False-Negative results from the LLM usage).

KPANIC indicates that a reliable kernel crash, kernel panic, or similarly
serious kernel availability impact was identified by the classification
workflow.

AL-KERNEL base severity for this report: MODERATE
KPANIC detected for this report: NO
Published priority for this report (same as in Subject): MODERATE REGULAR

These results are intended to support engineering triage. They are
machine-generated estimates, and cases marked for manual review should
be validated by a human security engineer before final disposition.
For more info read docs linked from here: https://kernelcve.org/
(and you can submit you own patch there to generate such a report
for non-existant CVE-id yet).

Note that in many cases this AI tool selects higher severity, than
real is (means you can expect Importants instead of Moderate 7.0 or
Moderates 7.0 instead of regular Moderates). If you see such cases,
please use reply email interface to add additional manual analyses
info to this particular CVE.
And please, please, let me know when you see Lows instead of Importants
or Important instead of Low (because particular for such cases I
need to tune this AI tool to make it better for this one and next similar).
My contact email for such notifications is alexanjelausa@gmail.com (and both
send reply to CVE record itself too and see "reply" button below for howto reply).