Cloudanix VulnDB

CVE-2026-99016

High · 7.8

CVSS

7.8

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in how the Linux kernel on certain RISC-V processors handles special memory addresses lets a regular user program secretly read and change parts of the operating system's own memory, which could let that user take full control of the computer.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Privilege Escalation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The futex atomic helpers on RISC-V pass a tagged user address directly to inline assembly (amoswap/amoadd/lr.w+sc.w) after access_ok() has only validated the untagged form; when tagged-address ABI is enabled this permits an unprivileged process to perform arbitrary read-modify-write operations on kernel virtual addresses that overlap with the linear map.

Why it matters to the business

A local attacker can escalate privileges to root and gain complete control of an affected RISC-V Linux system, potentially allowing theft of data, installation of persistent malware, or disruption of services with very high operational impact on any organization running the vulnerable kernel configuration.

How an attack unfolds

An attacker running as an unprivileged user enables the tagged-address ABI via prctl, crafts a futex address whose tag bits cause the raw pointer to alias a canonical kernel address in the linear map, then issues FUTEX_WAKE_OP (or similar) so that the kernel performs the atomic RMW on that kernel location and leaks the result through the comparison outcome, achieving both arbitrary write and a read oracle.

How to fix it

Upgrade the Linux kernel to a version containing the fix that untags the pointer before the atomic access in arch_futex_atomic_op_inuser and futex_atomic_cmpxchg_inatomic; rebuild and reboot all RISC-V systems; until patches are available, disable CONFIG_RISCV_ISA_SUPM or ensure the tagged-address ABI remains disabled for all users.

How to confirm the fix worked

Confirm the running kernel contains the commit that adds untagging before the inline-assembly memory operand; verify with `prctl` tests that tagged futex addresses no longer allow access outside the validated range; re-run regression tests for futex on RISC-V with Sv57 and PMLEN=16 configurations.

Typical attack path

  1. Enable tagged-address ABI with prctl(PR_SET_TAGGED_ADDR_CTRL)
  2. Calculate a tagged user pointer whose untagged form passes access_ok() but whose raw form aliases a kernel address
  3. Invoke futex with FUTEX_WAKE_OP or FUTEX_CMP_REQUEUE_PI on the tagged address
  4. Kernel performs atomic operation on the overlapping kernel address
  5. Use comparison result or side effects to read kernel memory or corrupt kernel state for privilege escalation

How to detect it

Search kernel audit logs and syscall traces for unusual futex calls originating from processes that have previously invoked prctl to set tagged-address controls; look for futex operations whose addresses have non-canonical high bits set; correlate with any subsequent unexpected kernel memory corruption or privilege-escalation events.

What your security team should do

  • Prioritize patching all RISC-V systems within the next maintenance window given the 2-day-old public disclosure
  • Audit kernel configs for CONFIG_RISCV_ISA_SUPM and consider disabling the feature if tagged addresses are not required
  • Add kernel version checks to vulnerability scanners and asset inventories
  • Monitor for any future EPSS increase or public exploit code

The record

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.

Affected packages

Ecosystem Package Introduced Fixed