CVE-2026-98469 in Linuxinfo

Summary

by MITRE • 10/18/2026

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

KVM: arm64: Fix AArch32 DBGBXVR<n> handling

The consolidation of the breakpoint and watchpoint register accessors switched DBGBXVR<n> from trap_bvr() to trap_dbg_wb_reg(). The latter selects backing storage with demux_wb_reg(), which only handles Op2 values 4 through 7. Since DBGBXVR<n> uses Op2 1, an AArch32 guest access hits KVM_BUG_ON() and marks the VM dead.

DBGBXVR<n> aliases DBGBVR<n>_EL1[63:32], and its AA32(HI) descriptor
already selects the upper half. Map Op2 1 to dbg_bvr[] alongside Op2 4,
restoring the pre-regression behavior.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 10/18/2026

The Linux kernel's KVM subsystem for ARM64 architectures recently addressed a critical regression in the handling of debug registers during AArch32 guest execution. This vulnerability stems from an architectural inconsistency introduced during the consolidation of breakpoint and watchpoint register accessors within the virtualization layer. Specifically, the refactoring process incorrectly mapped the DBGBXVR<n> register to use trap_dbg_wb_reg() instead of its original handler, trap_bvr(). The function trap_dbg_wb_reg() relies on demux_wb_reg() for selecting backing storage, a mechanism designed exclusively for watchpoint and breakpoint registers that utilize Op2 values ranging from 4 through 7. However, the DBGBXVR<n> register is defined to use Op2 value 1 in its architectural descriptor. Consequently, when an AArch32 guest attempts to access this specific debug register, the KVM logic fails to identify a valid storage path within the expected range and triggers a fatal kernel assertion via KVM_BUG_ON(). This immediate trigger results in the termination of the virtual machine instance, effectively causing a denial of service for any workload relying on AArch32 compatibility mode with hardware debugging features enabled.

From a technical perspective, this flaw represents an improper input validation or handling error where the software fails to account for all valid architectural variants of a register set. The DBGBXVR<n> registers are aliases for the upper 32 bits of the corresponding DBGBVR<n>_EL1 registers, which control breakpoint conditions and addresses. In AArch64 mode, these are accessed via Op2 values that align with standard breakpoint handling logic. However, in AArch32 compatibility mode, specifically when using high register access descriptors (AA32(HI)), the architecture mandates the use of Op2 1 to select the upper half of the 64-bit registers. The regression occurred because the consolidated accessor code did not map this specific Op2 value back to the dbg_bvr array used for breakpoint variable registers, leaving it unmapped or incorrectly routed to watchpoint-specific logic that does not support Op2 1. This misalignment between the architectural specification and the emulation implementation leads directly to the kernel panic observed in production environments running mixed-architecture guests with debugging capabilities active.

The operational impact of this vulnerability is severe for users requiring AArch32 guest support on ARM64 hosts, particularly those engaged in low-level software development, reverse engineering, or security research that relies on hardware breakpoints and watchpoints. Since the trigger results in a KVM_BUG_ON(), there is no graceful degradation; the entire virtual machine instance crashes immediately upon access. This disrupts continuous integration pipelines, halts debugging sessions abruptly, and can lead to data loss if unsaved work was present in the guest OS. Furthermore, because this involves kernel-level code execution within the hypervisor context, it compromises the stability of the host system's resource management for that specific VM instance. While it does not directly allow privilege escalation or arbitrary code execution by a malicious guest due to the immediate termination, it serves as an effective denial-of-service vector against virtualization services if triggered intentionally or accidentally during normal debugging operations.

To mitigate this vulnerability and prevent recurrence, developers must ensure that all architectural register aliases are correctly mapped in the KVM ARM64 implementation. The fix involves explicitly mapping Op2 value 1 to the dbg_bvr array alongside existing mappings for values 4 through 7 within the trap_dbg_wb_reg() logic or its underlying demux functions. This restores the pre-regression behavior where AArch32 guests can correctly access the upper halves of breakpoint registers without triggering fatal assertions. For system administrators and users, applying the updated kernel package that contains this patch is essential to restore stability for AArch32 workloads. Additionally, rigorous regression testing should be implemented in the KVM development cycle to verify that changes to register accessor consolidation do not break compatibility with legacy architectural modes like AArch32, ensuring that all valid Op2 values are accounted for and routed to their correct backing storage mechanisms as defined by the ARM Architecture Reference Manual.

Responsible

Linux

Reservation

09/25/2026

Disclosure

10/18/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!