* [CVE-2026-98467][MODERATE REGULAR] KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race
@ 2026-10-19 6:03 21% AL-KERNEL
0 siblings, 0 replies; 1+ results
From: AL-KERNEL @ 2026-10-19 6:03 UTC (permalink / raw)
To: kernel-cve
CVE: CVE-2026-98467
Priority: MODERATE REGULAR
AL-KERNEL base severity: MODERATE
KPANIC flag: NO
Patch: KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race
Commit: 970de111c087488e53cadf5480b94e0f695db985
Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=970de111c087488e53cadf5480b94e0f695db985
Original CVE announcement: https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98467
Analysis date: Mon, 19 Oct 2026 02:03:57 -0400
ActionableScore: 1
ActionableScore lower bound: unknown
Actionable bucket: Ordinary Moderate
Manual review required: NO
Summary:
A local VMM with access to arm64 nested KVM can race MMU notifier processing with shadow stage 2 teardown and cause a host kernel NULL pointer dereference and denial of service, but the locking semantics do not support a UAF or guest-to-host memory corruption primitive.
======================================================================
ABOUT THIS REPORT
======================================================================
The original Linux kernel CVE announcement for CVE-2026-98467 is available here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98467
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-2026-98467 MODERATE https://www.kernelcve.org/list/?q=CVE-2026-98467 CHECK WITH IMPACT FROM ORIG NN MODERATE | AEGIS IMPACT MODERATE_KPANIC AEGIS_AS=1 LEGACY=MODERATE RESULT=DIFF (final 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-476;CWE-667;BEST CVSS score: '4.7';DESCR 'A race in KVM arm64 nested virtualization can occur when stage2_apply_range temporarily drops kvm mmu_lock while nested stage 2 write protection or unmapping is in progress. Concurrent shadow MMU teardown can then set kvm arch mmu pgt to NULL before VNCR invalidation reads pgt ia_bits, resulting in a NULL pointer dereference in the host kernel. For the CVSS the PR:L value is selected because reliable triggering normally requires a local process with access to KVM and control over nested VM lifecycle or memory invalidation operations. AC:H is used because the failure depends on winning a teardown and MMU notifier timing window. The issue is not directly network reachable. The demonstrated impact is host denial of service through a kernel Oops or panic. The locking described by the change makes a stale pointer or UAF less plausible because pgt is observed as either valid or NULL while protected by mmu_lock. Automated impact decision path. The original SimpleNet classifier selected MODERATE_KPANIC. The primary LLM estimated paranoid CVSS 4.7 and the production ActionableScore returned 1 with recommendation Ordinary Moderate. The production rules then evaluated CVSS thresholds and ActionableScore thresholds. Recorded rule transitions were CVSS and initial triage stage MODERATE_KPANIC to MODERATE because the CVSS score, vector or bug class threshold rule was applied. The legacy KP specialist has no review artifact for this run. The legacy FD or DH downgrade specialist has no review artifact for this run. Exact triggered rule markers were DECREASED_TO_MODERATE_REGULAR_FROM_MODERATE7_BASED_ON_GUESSCVSS_AND_CIANNH and V41_INHERITED_KPANIC_PROMOTION_BLOCKED and MANUAL_REVIEW_REQUIRED. The independent weaker Aegis shadow evaluated CVSS 5.3 and ActionableScore 1 with primitive class CLASS_C and manual review RECOMMENDED. Its independently reconciled impact was MODERATE_KPANIC. The models disagreed but the aggregation rules retained the production result. The final reported impact is MODERATE.';YES REQUIRES MANUAL CHECK; ,and ActionableScore result is Ordinary Moderate (with actual score 1) MAYBE NULLPTR VIRT RACE HARDWARE LINUS DECREASED_TO_MODERATE_REGULAR_FROM_MODERATE7_BASED_ON_GUESSCVSS_AND_CIANNH V41_INHERITED_KPANIC_PROMOTION_BLOCKED MANUAL_REVIEW_REQUIRED - - 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
* +1 Reliable kernel crash or strong DoS. If shadow stage 2 teardown completes while `stage2_apply_range()` has dropped `kvm->mmu_lock`, the subsequent access to `pgt->ia_bits` dereferences NULL and can produce a host kernel Oops or panic.
* +1 Local below-host-admin trigger. A local VMM process with delegated `/dev/kvm` access can create and manage its own VM, memory backing, and VM lifecycle without possessing general host-administrator powers.
* -1 Reduced or delegated privilege. The attacker must have access to `/dev/kvm` and control of the affected nested VM. This is stronger than ordinary unrestricted local execution but weaker than host administration.
Important signals not awarded:
* No UAF signal. Teardown sets `kvm->arch.mmu.pgt` to NULL under `kvm->mmu_lock`, and the later access observes either a valid pointer or NULL. The patch does not establish use of freed page-table storage.
* No kernel-corruption signal. The demonstrated operation is a NULL read while evaluating `pgt->ia_bits`, not an OOB write, stale-object mutation, refcount operation, or controlled overwrite.
* No KVM guest-to-host exploitation leverage. A pure guest cannot be shown to control the host MMU-notifier operation and concurrent shadow-MMU teardown.
* No attacker-influenced lifetime bonus. The complete sequence is controlled by a local VMM or is a compound guest plus VMM sequence, not by guest code alone.
* No extra availability point. The Oops or panic is the same consequence already counted as strong DoS.
* No race penalty. Concurrency is required, but the supplied evidence does not establish that repeated attempts by a VMM are prohibitively narrow or uncontrollable.
* No C or I impact. There is no disclosure, protected-state modification, UAF, OOB access, or useful write primitive.
* No remote-reachability bonus. Network traffic does not directly reach this path.
* 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.
* V33 and V34 do not apply because there is no attacker-influenced active structured-state write or downstream metadata corruption.
* B4-PENDING does not apply because no authorization decision changes from DENY to ALLOW.
3. Reachability analysis
The supported attacker model is a local host VMM process with access to `/dev/kvm`, not an ordinary remote attacker and not necessarily host root. Such a process can create the affected VM, configure its memory backing, initiate MMU-notifier activity, and perform VM teardown concurrently.
A malicious nested guest can influence guest translation state, but the supplied path does not show that guest code alone can initiate the required host mapping invalidation and shadow-MMU teardown. A guest-only attack is therefore unproven. Combining guest control with independent VMM lifecycle control would be a compound trigger and is not scored as a guest-to-host primitive.
Access to `/dev/kvm` is generally delegated through device permissions and is not obtained through an attacker-created user or network namespace. `NamespaceScopedPrivilege=NO` reflects that the relevant authority is device access rather than a namespace-scoped capability.
Prior host configuration must expose KVM arm64 nested virtualization and `/dev/kvm` to the VMM account. No special physical hardware beyond an affected arm64 nested-virtualization environment is established. The race requires `stage2_apply_range()` to release the MMU lock while teardown advances, but a multithreaded VMM may attempt the sequence repeatedly.
4. Primitive and severity interpretation
The exact primitive is a race-dependent NULL pointer dereference. The affected pointer references active KVM page-table state, but the vulnerable use does not continue through freed storage. Teardown and access are serialized by `kvm->mmu_lock`, so the pointer is observed as valid or NULL rather than as a stale post-lifetime object.
There is no concrete repeated release or refcount mutation. No first operation leaves the same reference dangling for a second lifetime operation. The repeated-release signal, its paranoid bonus, and the real-UAF floors therefore do not apply.
This is `CLASS_C` because the demonstrated behavior is an invalid-state dereference with crash or DoS consequences and no independently useful corruption primitive. The practical consequence is a host kernel Oops or panic triggered by a local VMM with `/dev/kvm` access. Memory corruption, privilege escalation, VM escape, and guest-directed host read or write remain unsupported.
`ImportantCandidate=NO` because neither Class A nor a meaningful unresolved Class B primitive is present. `AutoDowngradeAllowed=YES` because the patch establishes a constrained NULL dereference rather than UAF, active-state corruption, authorization bypass, or cross-boundary write. Operationally this is an ordinary Moderate host-availability issue in deployments exposing arm64 nested KVM to less-trusted VMM processes.
5. One-sentence report phrase
A local VMM with access to arm64 nested KVM can race MMU notifier processing with shadow stage 2 teardown and cause a host kernel NULL pointer dereference and denial of service, but the locking semantics do not support a UAF or guest-to-host memory corruption primitive.
6. Manual review recommendation
MANUAL CHECK RECOMMENDED
Confirm whether the affected product exposes nested KVM to untrusted VMM processes and whether a guest-accessible management interface can independently induce the required host-side teardown. The established primitive itself remains crash-only.
7. Call-site confidence
Call-site confidence: high
======================================================================
UPSTREAM PATCH SUMMARY
======================================================================
Patch: KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race
Commit: 970de111c087488e53cadf5480b94e0f695db985
Upstream URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=970de111c087488e53cadf5480b94e0f695db985
Commit description:
Commit 7270cc9 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU
notifiers") introduced VNCR_EL2 invalidation in both kvm_nested_s2_unmap()
and kvm_nested_s2_wp().
However at the point of this being performed concurrent stage 2 teardown of
a nested guest can cause kvm->arch.mmu.pgt to be set to NULL.
This happens in kvm_flush_shadow_all() -> kvm_arch_flush_shadow_all() ->
kvm_free_stage2_pgd() and is performed under the kvm->mmu_lock.
Commit ec14c27 ("KVM: arm64: nv: Unmap/flush shadow stage 2 page
tables") introduced the teardown of the entire nested MMU range, which then
invokes stage2_apply_range() with resched=true:
mmu_notifier_invalidate_range_start()
-> ... -> kvm_mmu_notifier_invalidate_range_start()
-> kvm_mmu_unmap_gfn_range()
-> kvm_unmap_gfn_range()
-> kvm_nested_s2_unmap()
-> kvm_stage2_unmap_range()
-> __unmap_stage2_range()
-> stage2_apply_range()
This means that stage2_apply_range() can drop the kvm->mmu_lock and thus
concurrent progress can be made in lockstep with
kvm_arch_flush_shadow_all().
If kvm_arch_flush_shadow_all() advances ahead of stage2_apply_range() and
completes its operation it guarantees a NULL pointer deref.
Since kvm_free_stage2_pgd() is performed under the kvm->mmu_lock this will
either be observed NULL or not and serialised against
kvm_free_stage2_pgd().
Resolve the issue by abstracting the invalidation to a new function,
kvm_invalidate_vncr_ipa_all(), and check that the pgt is non-NULL before
dereferencing it.
Fixes: 7270cc9 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers")
Cc: [email protected]
Reviewed-by: Marc Zyngier <[email protected]>
Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]>
Tested-by: Jonathan Davies <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Oliver Upton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Changed files:
arch/arm64/kvm/nested.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=970de111c087488e53cadf5480b94e0f695db985
======================================================================
DETAILED REPORT METHODOLOGY
======================================================================
The original Linux kernel CVE announcement for CVE-2026-98467 can be found here:
https://lore.kernel.org/linux-cve-announce/?q=CVE-2026-98467
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: Not available
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 [email protected] (and both
send reply to CVE record itself too and see "reply" button below for howto reply).
^ permalink raw reply [relevance 21%]
Results 1-1 of 1 | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2026-10-19 6:03 21% [CVE-2026-98467][MODERATE REGULAR] KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race AL-KERNEL
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox