Re: [RFC PATCH] KVM: Ignore MMU notifiers for guest_memfd-only memslots

["David Hildenbrand (Arm)" <david@kernel.org>]

On 6/15/26 19:47, Sean Christopherson wrote:
> On Mon, Jun 15, 2026, sashiko-bot@kernel.org wrote:
>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>> --- a/virt/kvm/kvm_main.c
>>> +++ b/virt/kvm/kvm_main.c
>> [ ... ]
>>> @@ -592,6 +592,10 @@ static __always_inline kvm_mn_ret_t kvm_handle_hva_range(struct kvm *kvm,
>>>  			unsigned long hva_start, hva_end;
>>>  
>>>  			slot = container_of(node, struct kvm_memory_slot, hva_node[slots->node_idx]);
>>> +
>>> +			if (kvm_slot_has_gmem(slot) && kvm_memslot_is_gmem_only(slot))
>>> +				continue;
>>> +
>>
>> [Severity: Critical]
>> Does this change inadvertently introduce a regression in the pfncache retry
>> protocol?
>>
>> Looking at the pfncache framework, it maps guest memory into kernel space and
>> explicitly drops the page reference after mapping it:
>>
>> virt/kvm/pfncache.c:hva_to_pfn_retry() {
>>     ...
>>     kvm_release_page_clean(page);
>>     ...
>> }
>>
>> It appears to rely entirely on KVM's MMU notifiers (kvm->mmu_invalidate_seq)
>> to invalidate the cache when the page is unmapped by the host.
>>
>> If a VMM defines a guest_memfd-backed memslot with KVM_MEMSLOT_GMEM_ONLY
>> but still provides a valid anonymous user mapping as its userspace_addr,
>> could this regression lead to a use-after-free?
> 
> Sadly, yes.  To land this, we would need to first teach the gfn_to_pfn_cache code
> to be able to pull directly from guest_memfd.  I forget if anyone is working on
> that.

For completeness, I think this is what you are looking for:

https://lore.kernel.org/r/20260420154720.29012-1-itazur@amazon.com

-- 
Cheers,

David