CVE-2026-63950: mm/rmap: initialize nr_pages to 1 at loop start in try_to_unmap_one

In the Linux kernel, the following vulnerability has been resolved:

mm/rmap: initialize nrpages to 1 at loop start in trytounmapone

Initialize nrpages to 1 at the start of each loop iteration, like folioreferencedone() does.

Without this, nrpages computed by a previous foliounmapptebatch() call can be reused on a later iteration that does not run foliounmapptebatch() again.

mmap a 64K large folio with MAPANONYMOUS | MAPDROPPABLE, then call madvise(MADVFREE), then make the last page device-exclusive via HMMDMIRROREXCLUSIVE.

Trigger node reclaim through sysfs. Now, in trytounmapone(), we will first clear the first 15 out of 16 entries mapping the lazyfree folio. This will set nrpages to 15. In the next pvmw walk, this nrpages 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 folioreferencedone(), 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 folioreferencedone(), and the kernel blows up at folioremovermapptes in trytounmapone 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.