PT-2026-61267 · Linux · Linux
CVE-2026-63950
·
Publicado
2026-07-19
·
Atualizado
2026-07-19
CVSS v3.1
7.8
Alta
| Vetor | AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
In the Linux kernel, the following vulnerability has been resolved:
mm/rmap: initialize nr pages to 1 at loop start in try to unmap one
Initialize nr pages to 1 at the start of each loop iteration, like
folio referenced one() does.
Without this, nr pages computed by a previous folio unmap pte batch() call
can be reused on a later iteration that does not run
folio unmap pte batch() again.
mmap a 64K large folio with MAP ANONYMOUS | MAP DROPPABLE, then call
madvise(MADV FREE), then make the last page device-exclusive via
HMM DMIRROR EXCLUSIVE.
Trigger node reclaim through sysfs. Now, in try to unmap one(), we will
first clear the first 15 out of 16 entries mapping the lazyfree folio.
This will set nr pages to 15. In the next pvmw walk, this nr pages gets
reused on a device-exclusive pte, thus potentially corrupting folio
refcount/mapcount.
At the moment, I have a userspace program which can make the kernel spit
out a trace, but the blow up is in folio referenced one(), because there
are existing bugs in the interaction between device-private and rmap
(which too I am investigating). I did a one liner kernel change to avoid
going into folio referenced one(), and the kernel blows up at
folio remove rmap ptes in try to unmap one which is what I wanted.
Note that the bug is there not since file folio batching but lazyfree
folio batching, since device-exclusive only works for anonymous folios.
Userspace visible effect is simply kernel crashing somewhere due to
refcount/mapcount corruption.
Correção
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Identificadores relacionados
Produtos afetados
Linux