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

[David Hildenbrand (Arm)]

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.
> 
> 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.

No need for more shaky seals.

-- 
Cheers,

David