PT-2026-121993
CVE-2026-99016
·
Published
2026-10-23
·
Updated
2026-10-23
Description by
Score
N/A
Not availableNo severity ratings or metrics are available. When they are, we'll update the corresponding info on the page.
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.
Found an issue in the description? Have something to add? Feel free to write us 👾