From mboxrd@z Thu Jan 1 00:00:00 1970 From: AL-KERNEL To: kernel-cve@kernelcve.org Subject: [CVE-2026-98467][MODERATE REGULAR] KVM: arm64: nv: Fix null ptr deref on nested wp/unmap, teardown race Date: Mon, 19 Oct 2026 02:03:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AL-KERNEL-CVE: CVE-2026-98467 X-AL-KERNEL-Priority: MODERATE REGULAR X-AL-KERNEL-Severity: MODERATE REGULAR X-AL-KERNEL-Base-Severity: MODERATE X-AL-KERNEL-KPANIC: NO X-AL-KERNEL-ActionableScore: 1 X-AL-KERNEL-ActionableScore-Lower: unknown X-AL-KERNEL-Commit: 970de111c087488e53cadf5480b94e0f695db985 List-Id: 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: stable@vger.kernel.org Reviewed-by: Marc Zyngier Signed-off-by: Lorenzo Stoakes (ARM) Tested-by: Jonathan Davies Link: https://patch.msgid.link/20260901-kvm-arm-nested-virt-fix-v3-2-b154676f7e4c@kernel.org Signed-off-by: Oliver Upton Signed-off-by: Greg Kroah-Hartman 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 alexanjelausa@gmail.com (and both send reply to CVE record itself too and see "reply" button below for howto reply).