PT-2026-121993

CVE-2026-99016

·

Publicado

2026-10-23

·

Atualizado

2026-10-23

Descrição por

Pontuação
N/A
Não disponível

Nã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.
Fornecedores
Produtos afetados
Identificadores relacionados
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾