PT-2026-121993
CVE-2026-99016
·
Publicado
2026-10-23
·
Atualizado
2026-10-23
Descrição por
Pontuação
N/A
Não disponívelNão há classificações de severidade ou métricas disponíveis. Quando houver, atualizaremos as informações correspondentes na página.
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.
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾