PT-2026-121993

CVE-2026-99016

·

تاريخ النشر

2026-10-23

·

تاريخ التحديث

2026-10-23

الوصف من

الدرجة
N/A
غير متوفر

لا تتوفر حاليًا تقييمات أو مقاييس للخطورة. سنحدّث المعلومات المقابلة في الصفحة فور توفرها.

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.
المورّدون
المنتجات المتأثرة
المعرّفات ذات الصلة
وجدت خطأً في الوصف؟ لديك ما تضيفه؟ لا تتردد في مراسلتنا 👾