CVE-2026-67846 in BOOM
Summary
by MITRE • 08/18/2026
Berkeley Out-of-Order Machine (BOOM) commit 5223e44cfeb26f41380057a2eb4d651197475f69 contains a potential incorrect privilege assignment issue in the v3 and v4 NBDTLB implementations. The raw mstatus.SUM value participates in the read and write permission logic without an explicit local satp.MODE validity check at the use site
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified within the Berkeley Out-of-Order Machine, specifically linked to commit 5223e44cfeb26f41380057a2eb4d651197475f69, represents a critical flaw in the privilege enforcement mechanisms of its virtual memory subsystem. This issue resides within the implementation of the v3 and v4 NBDTLB, which are responsible for managing translation lookaside buffers used to translate virtual addresses to physical addresses during instruction fetches and data accesses. The core technical deficiency involves an improper handling of the SUM bit located in the mstatus register when determining read and write permissions for user-mode memory access. In RISC-V architecture, the SUM bit is designed to allow or restrict supervisor software from accessing user pages, thereby providing a mechanism for privilege escalation control within virtualized environments or operating systems that rely on specific page table isolation properties.
The fundamental flaw arises because the logic governing permission checks utilizes the raw value of mstatus.SUM without first validating whether the current address translation context is actually in user mode via an explicit check against satp.MODE. The satp register holds the state of the active page tables and includes a MODE field that indicates the privilege level at which the current memory access should be evaluated. By bypassing this validity check, the hardware logic may incorrectly apply permissions intended for supervisor-level interactions to user-mode contexts, or vice versa, depending on how the SUM bit interacts with other control signals in an undefined state. This lack of explicit validation means that if satp.MODE indicates a non-user mode but mstatus.SUM is set, the system might erroneously grant access privileges that should be denied, creating a discrepancy between the intended security policy and the actual hardware behavior.
From an operational impact perspective, this vulnerability can lead to unauthorized memory accesses where user-space applications or less privileged processes gain read or write capabilities into regions of memory they are not supposed to reach. This effectively bypasses the isolation boundaries enforced by the operating system kernel, potentially allowing a malicious actor to extract sensitive data from other processes or inject code into protected areas of memory. Such an outcome constitutes a severe breach of confidentiality and integrity within the computing environment. The absence of proper privilege checks aligns with CWE-269, which classifies Improper Privilege Management, as it allows actions that require higher privileges to be performed by lower privileged entities due to flawed logic in access control mechanisms.
Furthermore, this type of vulnerability facilitates lateral movement and escalation within a compromised system environment. An attacker exploiting this flaw could transition from user space to supervisor or kernel space without proper authentication or authorization checks, which corresponds to the ATT&CK technique T1068, Exploitation for Privilege Escalation. The ability to manipulate memory permissions at the hardware level means that traditional software-based mitigations may be insufficient if the underlying silicon logic does not enforce these constraints correctly. This highlights a critical intersection between microarchitecture design and system security, where assumptions about register states must be rigorously validated before being used in permission decisions.
Mitigation strategies for this vulnerability require immediate attention from hardware designers and firmware developers responsible for RISC-V implementations based on the BOOM architecture. The primary remediation involves modifying the NBDTLB logic to explicitly check the satp.MODE field prior to evaluating mstatus.SUM when determining access permissions. This ensures that privilege checks are context-aware and only apply relevant restrictions or allowances based on the actual execution mode of the current transaction. Additionally, comprehensive verification through formal methods can help identify such logical gaps in future designs by mathematically proving that all paths leading to memory permission decisions correctly account for privilege levels. Software-level mitigations may also involve ensuring that operating systems do not rely solely on hardware enforcement and implement additional checks within their virtual memory management routines to detect anomalies, although the root cause must be addressed at the silicon level to ensure robust security posture against sophisticated attacks targeting microarchitectural flaws.