From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B148838DC65 for ; Tue, 4 Aug 2026 12:05:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785845157; cv=none; b=Tp+VC4XIM8KNAmB/snYSV/gD4WbUP7BYvUxKEyiYD5qh4Atym4DdCuyVmMCBS63jszDOwGThxTZXxq4aGoMBsRtcqz5i6OVNH2hkpHP8IP+0DPTG58z9WMHwc7fgCPSnV9gGpeZ3S0JBPvDqxGKherR+naE8IIKDuWWgvjDqTNw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785845157; c=relaxed/simple; bh=ShgJllGtoj3B6lj3SHwP+387ixSZNj2YWvPFDV6BseQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BGXXxnyMGw1Th+wK2sB4PoML/yqLV5U0A0dbA7BVbcpjF0FMl+Pk1e7muZ6O/E72x4p3P9c3zOivfd1gVFvfxUZ4kcBabaXsyw4iaOIbZouM4wS9XAMz7vejX2OOZu1REh4cPW0NRfjfHCEvF+ABdLQgefWR/RQNwoOPS9cRl0U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Fc+V+8IK; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=cAIhJJ5i; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Fc+V+8IK"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="cAIhJJ5i" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785845153; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7VbhR/EeseCGUhv0h0yNN2Py/m+SxPzo7FfzMk4g7pY=; b=Fc+V+8IKcZCcp6czP4p2omH3FWU8+EnyxkruDA0g15z08MySPBOaaq3FTUC6F5ClD3O2rd 36ONEIWQtToahldeprLEYidSpcqA7+d2DHNNtHRjS+MbL1dliXGq4rUY4nt5wzJC2b+X+M gZ2Wzfd5km3LLilFPutcFkhOrzethJI= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-216-2-M5-ChmMV2V13PC3mVqmg-1; Tue, 04 Aug 2026 08:05:47 -0400 X-MC-Unique: 2-M5-ChmMV2V13PC3mVqmg-1 X-Mimecast-MFC-AGG-ID: 2-M5-ChmMV2V13PC3mVqmg_1785845146 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-47f83416551so4290353f8f.3 for ; Tue, 04 Aug 2026 05:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1785845146; x=1786449946; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=7VbhR/EeseCGUhv0h0yNN2Py/m+SxPzo7FfzMk4g7pY=; b=cAIhJJ5iypZOUTPkcOfJVA/+T+eNpiURGumey1wvCCiEqCPTbkXpjDSGd2kXAlHDgI it6fL70CYJYt++jBX6Pg7dkNwpXmtH4S8MZJHfIyPz7qSzaoI7AJWObi6LyXq1QAfh/N Nr2H8i0KrzVACddd0yxSRxEE6+k/odK4HgyRlQphWwyA20wzRZgCDegc5FmKqS2c5ye6 RpHmIy+9gHvLWdHzrHXywY3ZWc4sDBUJ7s6R48hgs3rRopd8PtRMx2yA9PQRiWon403Q VhxLqw3teQZewLTMwxlTswIepR9ZxT8+XJNtkWPVglCnSf0NucOUpwbbhFuuxmtfrjBV 3ijw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785845146; x=1786449946; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=7VbhR/EeseCGUhv0h0yNN2Py/m+SxPzo7FfzMk4g7pY=; b=Jf7CabhWFinoq4/NAvQ+QD5LaNNyb2x5n5y1Vz22RQy/yCjIkC/lsu1syabY4t4HsF TCDNCJ8p5GcV6elLWKE9mO5LflP4QKY6IyEokQYLw48i8KcimwRZhgPK/dxST60BsJOZ jp097CxqJpQW9LXzD8TngyEst1KzogQRgX6axhWSNtFi7URAcV+jpsCbDv85jFARVZha s4znEWbq0hO4xeVwvloHGhg6ikCihJwlYEtyvubW5gW/ZvSDzziGnPdH36f765a3CkMU jmmS7ybNLNr3ORQqgZJrSXVJXlM7R2hiry5I2iaEYCr2slxQ5H9lSKg5+H35ToFE58Ra KmUg== X-Gm-Message-State: AOJu0YwXK5Ssw7BqYFhMyRIbvx+mPCXHK8IYBUBAGlqW5GQt1YJNA42r 4z281TL2z1pO+Rkh6kOUUSEHfRTKRjvaltwD/eCWNPna9T6XCCLr7cR0x9GpxWCXnsF7WOjzqu+ QxV6iVIuP0EuRZDICDBZxLguYIfO6TJmu4GGH9YH4E2JV8DZFoaH6Mdgr9WUdzXBeEKnnxiNKkZ erlhmlYJOdVa8V869dsrjKLuEzhTUHMA5wox03uDEuyHs+3R6nNA== X-Gm-Gg: AR+sD11/2+4O+KA241rUaJbV6z386gWuAC2Jb/MA+uSXw+2TyWNXpFFH4Pqn9N23LA4 xHRawlcoPVSi0kjnHmiHB5mjWutoXWyDJkKpnZnNKtJRNIbZ69EZIJhE6Zh5WTcLBik/h224fM/ q3aZmXP54HIgs1yPysKyTZxP29CvqCfTfGbWRtU1dHJ7cjeC6MdpNPVT99lRLkT4a8Wof5VKTZ3 6tOeGUgv1hi50wE9fvudb6qsFi3YtnPf/b0UM1G9lTcYUFtG/zizGCh6vVEfndJvj1qdt4qSh+M oAXiaZlGMCNA22ICR3Sb5vseWBnFQJpR9tBuMf0DE6+ujathTrD/tpfDOFzSHNPN/J80z4OgLYF tUqOM8jXdM8TUHfbpVOTLKga0oJSLyVTbzWTGvp3FZh1pHm5JeyheNFSP2823uPQm5B2VkgPXSs ER2ck= X-Received: by 2002:a05:6000:2989:20b0:47f:7154:9dfc with SMTP id ffacd0b85a97d-47fd72a8e68mr29813808f8f.9.1785845146115; Tue, 04 Aug 2026 05:05:46 -0700 (PDT) X-Received: by 2002:a05:6000:2989:20b0:47f:7154:9dfc with SMTP id ffacd0b85a97d-47fd72a8e68mr29813677f8f.9.1785845145601; Tue, 04 Aug 2026 05:05:45 -0700 (PDT) Received: from [192.168.10.48] ([151.95.34.92]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fd4562667sm45367660f8f.24.2026.08.04.05.05.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 05:05:43 -0700 (PDT) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Alex Williamson , bcm-kernel-feedback-list@broadcom.com, Boris Brezillon , Christian Koenig , David Hildenbrand , dri-devel@lists.freedesktop.org, Fei Li , Huang Rui , linux-mm@kvack.org, linux-s390@vger.kernel.org, Michal Hocko , Peter Xu , Sergio Lopez , Sean Christopherson , Thomas Zimmermann , stable@vger.kernel.org Subject: [PATCH v2 4/6] kvm: apply VM_READ/VM_WRITE checks to all VMA types Date: Tue, 4 Aug 2026 14:05:26 +0200 Message-ID: <20260804120529.1730187-5-pbonzini@redhat.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260804120529.1730187-1-pbonzini@redhat.com> References: <20260804120529.1730187-1-pbonzini@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The VM_READ and VM_WRITE flags are checked only at the very end of hva_to_pfn(). For both the hva_to_pfn_remapped() case and for regular mappings, this adds unnecessary cases and inconsistent error behavior. For hva_to_pfn_remapped(), the code is relying on fixup_user_fault() to detect this situation. This is fragile because hva_to_pfn_remapped() returns different error codes for a !VM_WRITE VMA depending on whether the PTE happens to be mapped: * if the PTE is present, follow_pfnmap_start() sets args.writable to false and KVM_PFN_ERR_RO_FAULT is returned; * if no PTE is present, fixup_user_fault(FAULT_FLAG_WRITE) returns -EFAULT after checking vma_permits_fault(), and hva_to_pfn() ends up returning KVM_PFN_ERR_FAULT. With this patch KVM_PFN_ERR_RO_FAULT is returned uniformly. Likewise, a PROT_NONE pfnmap VMA would be mapped into the guest if the PTE was pte_present()[1] when the guest attempted to read it; with the patch instead KVM uniformly returns KVM_PFN_ERR_FAULT. Doing the check early avoids these special cases and also sidesteps the issue pointed out at https://sashiko.dev/#/patchset/20260731160514.1101989-1-pbonzini%40redhat.com. For regular mappings a PROT_READ VMA, if placed in a writable memslot, would return KVM_PFN_ERR_FAULT instead of KVM_PFN_ERR_RO_FAULT when the guest writes to it. This would cause a -EFAULT exit to userspace, instead of triggering emulation as the VM_IO|VM_PFNMAP arm would do; however it should be considered part of the KVM API because mmu_stress_test relies on it. Still, even with this snag about the returned pfn error code, pull the vm_flags checks in front so that they are done for all VMAs and the above inconsistency goes away for the VM_IO|VM_PFNMAP case. [1] on x86, for example, such a page would have _PAGE_PRESENT clear but _PAGE_PROTNONE set Fixes: 28e3918179aa ("drm/gem-shmem: Track folio accessed/dirty status in mmap") Cc: stable@vger.kernel.org Signed-off-by: Paolo Bonzini --- virt/kvm/kvm_main.c | 34 ++++++++++++++++------------------ 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 45e784462ec6..576bcb21be3a 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2925,17 +2925,6 @@ static int hva_to_pfn_slow(struct kvm_follow_pfn *kfp, kvm_pfn_t *pfn) return npages; } -static bool vma_is_valid(struct vm_area_struct *vma, bool write_fault) -{ - if (unlikely(!(vma->vm_flags & VM_READ))) - return false; - - if (write_fault && (unlikely(!(vma->vm_flags & VM_WRITE)))) - return false; - - return true; -} - static int hva_to_pfn_remapped(struct vm_area_struct *vma, struct kvm_follow_pfn *kfp, kvm_pfn_t *p_pfn) { @@ -3008,20 +2997,29 @@ kvm_pfn_t hva_to_pfn(struct kvm_follow_pfn *kfp) retry: vma = vma_lookup(current->mm, kfp->hva); - if (vma == NULL) + /* + * GUP failed. It could be an inaccessible mapping, a pfnmap one, + * or the page might be absent. + */ + + if (vma == NULL || unlikely(!(vma->vm_flags & VM_READ))) { pfn = KVM_PFN_ERR_FAULT; - else if (vma->vm_flags & (VM_IO | VM_PFNMAP)) { + } else if ((kfp->flags & FOLL_WRITE) && unlikely(!(vma->vm_flags & VM_WRITE))) { + /* + * Exit to userspace for PROT_READ mappings in a writable + * memslot, as this is part of the API. + */ + pfn = vma->vm_flags & (VM_IO | VM_PFNMAP) ? KVM_PFN_ERR_RO_FAULT : + KVM_PFN_ERR_FAULT; + } else if (vma->vm_flags & (VM_IO | VM_PFNMAP)) { r = hva_to_pfn_remapped(vma, kfp, &pfn); if (r == -EAGAIN) goto retry; if (r < 0) pfn = KVM_PFN_ERR_FAULT; } else { - if ((kfp->flags & FOLL_NOWAIT) && - vma_is_valid(vma, kfp->flags & FOLL_WRITE)) - pfn = KVM_PFN_ERR_NEEDS_IO; - else - pfn = KVM_PFN_ERR_FAULT; + pfn = kfp->flags & FOLL_NOWAIT ? KVM_PFN_ERR_NEEDS_IO : + KVM_PFN_ERR_FAULT; } mmap_read_unlock(current->mm); return pfn; -- 2.55.0