Re: [PATCH v2] KVM: x86: Take SRCU in kvm_zap_gfn_range()

[Huang, Kai]

On Wed, 2026-08-26 at 02:39 +0800, Chengfeng Ye wrote:
> kvm_zap_gfn_range() walks memslots and rmaps and may drop mmu_lock to
> reschedule. Callers that do not already hold kvm->srcu (or slots_lock)
> can race with memslot deletion: synchronize_srcu_expedited() does not
> wait, kvm_free_memslot() frees the old slot and its rmap, and the zap
> resumes on freed memory.
> 
> The VFIO noncoherent-DMA path hits this by zapping the entire GPA
> space without SRCU. KASAN reported:
> 
>   BUG: KASAN: vmalloc-out-of-bounds in slot_rmap_walk_next+0x82/0x1c0
>   Read of size 8 at addr ffffc900005c1008
>   Call Trace:
>    slot_rmap_walk_next+0x82/0x1c0
>    __kvm_rmap_zap_gfn_range+0x17a/0x280
>    kvm_zap_gfn_range+0x2a6/0x6a0
>    kvm_vfio_set_attr+0x576/0x770
>    kvm_device_ioctl+0x1ff/0x3b0
> 
> Take SRCU inside kvm_zap_gfn_range() so every caller is covered.
> Nesting with an existing kvm->srcu critical section is fine; the
> helper uses a local index. Drop the now-redundant SRCU pair from
> __kvm_set_or_clear_apicv_inhibit().
> 
> Fixes: 362ff6dca541 ("KVM: x86/mmu: Zap KVM TDP when noncoherent DMA assignment starts/stops")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Chengfeng Ye <nicoyip.dev@xxxxxxxxx>

Reviewed-by: Kai Huang <kai.huang@xxxxxxxxx>

Btw, I found kvm_noncoherent_dma_assignment_start_or_stop() was added at
July/2023 and the SRCU lock to __kvm_set_or_clear_apicv_inhibit() was added at
Nov/2022, so I think this patch should be able to be applied to stable kernels
cleanly (if no other conflicts).