summaryrefslogtreecommitdiff
path: root/samples/check-exec
diff options
context:
space:
mode:
authorSamiullah Khawaja <skhawaja@google.com>2026-10-31 20:35:40 +0000
committerDavid Hildenbrand (Arm) <david@kernel.org>2026-11-03 20:20:53 +0100
commit71555ae8c7572fd99158013ca2e29187c5d2508d (patch)
tree6fffba8ad18ac8dd88ae282de03c6bb06ea6980d /samples/check-exec
parenteadce52a9ef657d561b3e76c9b5f178bd99735f5 (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