Re: [PATCH 0/2] mm/memfd: add F_SEAL_PUNCH_HOLE

[Samiullah Khawaja]

On Fri, Oct 30, 2026 at 03:39:40PM +0100, David Hildenbrand (Arm) wrote:
> On 10/30/26 13:11, Jason Gunthorpe wrote:
> > On Fri, Oct 30, 2026 at 11:20:30AM +0100, David Hildenbrand (Arm) wrote:
> > > On 10/26/26 23:05, Samiullah Khawaja wrote:
> > > > This series introduces F_SEAL_PUNCH_HOLE, a new memfd seal that prevents
> > > > holes from being punched into a shmem or hugetlbfs memfd while leaving
> > > > the file fully writable.
> > > >
> > > > Background
> > > > ==========
> > > >
> > > > Drivers such as udmabuf and iommufd (via IOMMU_IOAS_MAP_FILE) use
> > > > memfd_pin_folios() to pin the folios backing a memfd and hand them to a
> > > > device for DMA. Pinning keeps those folios allocated, but it does not
> > > > keep them in the file. If userspace later calls
> > > > fallocate(FALLOC_FL_PUNCH_HOLE) or madvise(MADV_REMOVE) on the range,
> > > > the folios are dropped from the page cache while the device continues
> > > > to use them. The pin holder is never notified, and from that point on
> > > > the device and the file silently diverge.
> > >
> > > We have the exact same situation when userspace maps anonymous folios into vfio
> > > and then desides to MADV_DONTNEED the pages. Or any other memory backend that is
> > > used for such purposes.
> > >
> > > User space must not zap/punch things that might be pinned elsewhere.
> > >
> > > That's not specific to memfd, udmabuf, iommufd or anything else.
> > >
> > > I don't see a reason to make userspace (that should not shoot itself into the
> > > foot) a kernel feature it must activate itself to not shoot itself into the foot.

Agreed, for normal use this is userspace's problem. The seal was meant
for the kernel to cheaply verify at preserve time that nothing was
punched.

> > The issue is live update doesn't preserve those background punched
> > folios and now we have created an UAF attack on the kernel across
> > kexec if you don't do something about it.
> >
> > There was some notion here that with the right sealing flags we could
> > tell if everything was 'live update compatible' and then know that
> > these attacks are impossible.
> Just remember that there was any hole punch and refuse to live update this instance.
>
> We could likely implement "we saw hole punch on a pinned folio" as well, but I
> don't think that's required initially.

If I understand correctly, you mean recording on the memfd that a hole
punch happened, and refusing the live update if it did? That would work
and is much cheaper than what we do today, where iommufd walks all the
mapped pages at preserve time. For truncate, the existing F_SEAL_SHRINK
is enough or I can record that also on the memfd. I will send patches
for this.

> No need for more shaky seals.
>
> --
> Cheers,
>
> David

Thanks for the feedback,
Sami