diff options
| author | Samiullah Khawaja <skhawaja@google.com> | 2026-10-31 20:35:40 +0000 |
|---|---|---|
| committer | David Hildenbrand (Arm) <david@kernel.org> | 2026-11-03 20:20:53 +0100 |
| commit | 71555ae8c7572fd99158013ca2e29187c5d2508d (patch) | |
| tree | 6fffba8ad18ac8dd88ae282de03c6bb06ea6980d /samples/check-exec | |
| parent | eadce52a9ef657d561b3e76c9b5f178bd99735f5 (diff) | |
mm/gup: check folio->mapping under folio lock in memfd_pin_folios()
memfd_pin_folios() pins folios from the page cache without taking the
folio lock. khugepaged or MADV_COLLAPSE can therefore replace a folio
after checking its refcount while memfd_pin_folios() still pins the old
folio. The caller then receives a folio which is no longer part of the
memfd.
For udmabuf and iommufd, this can cause data corruption: DMA accesses
the detached folio rather than the live memfd contents. DMA reads can
return stale data, while DMA writes update the detached copy and are
lost from the live memfd. The detached folio remains pinned, so these
accesses do not constitute a use-after-free or target another
application's memory. For memfd live update, the stale contents can
reappear in the memfd after handover.
Lock the folio and recheck folio->mapping before pinning it, like other
page cache users do. If the folio was removed, retry the folio lookup
from the index that was removed.
Fixes: 89c1905d9c14 ("mm/gup: introduce memfd_pin_folios() for pinning memfd folios")
Reported-by: Andy Lutomirski <luto@amacapital.net>
Closes: https://lore.kernel.org/all/CALCETrV5eqg6d9=+BQhCpRwBNe3aCQiut8vxPBs8b7PToqjaHg@mail.gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Samiullah Khawaja <skhawaja@google.com>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>
Link: https://patch.msgid.link/20261031203540.2282507-1-skhawaja@google.com
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
Diffstat (limited to 'samples/check-exec')
0 files changed, 0 insertions, 0 deletions
