CVE-2026-99016 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
riscv: futex: untag the user pointer before the atomic access
access_ok() checks untagged_addr(uaddr), but arch_futex_atomic_op_inuser() and futex_atomic_cmpxchg_inatomic() hand the raw uaddr to the inline asm amoswap/amoadd/.../lr.w+sc.w through the "+m" (*uaddr) operand. When the tagged address ABI is enabled (CONFIG_RISCV_ISA_SUPM, prctl PR_SET_TAGGED_ADDR_CTRL with PMLEN != 0), those two addresses differ: a user pointer whose top PMLEN bits hold a tag passes access_ok() after untagging, but the atomic is then performed on the still-tagged raw address.
Supervisor-mode data accesses are not subject to the U-mode pointer masking (that is governed by menvcfg.PMM, which the kernel does not set), so hardware does not strip the tag for the kernel's own access. With Sv57 and PMLEN=16 the tag bits overlap the canonical-address bits, so a tagged pointer can name a canonical kernel virtual address (e.g. in the linear map) whose untagged form is a valid user address. An unprivileged process can thus make FUTEX_WAKE_OP perform an atomic read-modify-write on an arbitrary kernel address, with the matching FUTEX_OP_CMP_* result serving as a read oracle.
get_user()/put_user()/raw_copy_{to,from}_user() already untag the pointer
after the access_ok() check; do the same in the futex helpers so the atomic operates on the address that was actually validated.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The identified vulnerability resides within the RISC-V implementation of the Linux kernel's futex subsystem, specifically affecting operations involving tagged user pointers when the Supervisor-mode Pointer Masking feature is enabled. This security flaw stems from an inconsistency in how memory addresses are handled during atomic read-modify-write operations. The access_ok() function correctly untags the user pointer before validating its accessibility within the user address space. However, subsequent functions such as arch_futex_atomic_op_inuser and futex_atomic_cmpxchg_inatomic pass the raw, tagged uaddr directly to inline assembly instructions like amoswap or lr.w+sc.w via memory operands. This discrepancy means that while the kernel validates an untagged version of the address, it performs atomic operations on a potentially different physical location defined by the tagged address.
The root cause is tied to how hardware handles pointer masking in supervisor mode. When CONFIG_RISCV_ISA_SUPM is enabled and PMLEN is non-zero, user pointers may contain tags in their upper bits governed by menvcfg.PMM. The kernel does not set this control register bit for its own accesses, meaning the hardware does not strip these tag bits during supervisor-mode operations. Consequently, if a tagged pointer has top bits that overlap with canonical address bits, particularly under Sv57 paging with PMLEN=16, it can map to a valid kernel virtual address in the linear map even though its untagged form points to user space. This architectural behavior allows an attacker to bypass standard memory isolation boundaries by leveraging the difference between validated and executed addresses.
The operational impact of this vulnerability is severe, as it enables an unprivileged process to perform atomic read-modify-write operations on arbitrary kernel memory addresses. By utilizing FUTEX_WAKE_OP with carefully crafted tagged pointers, a local user can target specific kernel locations that would otherwise be inaccessible. Furthermore, the mechanism provides a side-channel for information disclosure; by observing the results of matching FUTEX_OP_CMP_* instructions, an attacker can deduce values stored at those arbitrary kernel addresses. This effectively transforms the futex subsystem into a powerful read oracle, compromising both confidentiality and integrity of kernel memory structures.
To mitigate this risk, the Linux kernel has been patched to ensure that user pointers are untagged before any atomic access is performed. The fix aligns the behavior of futex helpers with existing patterns used in get_user, put_user, and raw_copy_{to,from}_user functions, which already perform untagging after validation checks. By stripping the tag bits prior to invoking inline assembly operations, the kernel ensures that the address subjected to atomic modification is identical to the one validated by access_ok(). This correction eliminates the discrepancy between user-space intent and supervisor-mode execution context, thereby closing the pathway for arbitrary kernel memory writes and reads.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system fails to properly sanitize input data (the tagged pointer) before processing it in a privileged context. It also relates to CWE-787 Out-of-bounds Write due to incorrect address calculation or interpretation of memory boundaries. In terms of adversary tactics, this flaw facilitates privilege escalation and information gathering consistent with ATT&CK techniques such as T1059 Command and Scripting Interpreter for local exploitation vectors and potentially T1046 Network Service Scanning if leveraged for broader reconnaissance within the host environment. The resolution underscores the importance of rigorous address handling in kernel subsystems that interact directly with user-space memory, particularly when hardware features like pointer masking introduce complex mapping behaviors between user and supervisor modes.