From nobody Tue Sep 29 13:20:14 2026 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 C144D1FE471 for ; Fri, 7 Aug 2026 13:46:41 +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=1786110406; cv=none; b=K/aBnABGD6zgG9cYexqZE7jH36wRfD5R7vUg4ds0DAIDasRxT3IY2M86JlI1qI4PT+Q5TLdR6xOTnjawZ+CWs9n6I+ao3lckY6rf5fdn3wS46yDj+UqdYHohiKSguR6zgxh+3bQRj+RV66XFSahgvzb9MbZRj/igXlqiYwUWOgI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786110406; c=relaxed/simple; bh=8ZCbd1r0p1hFVRN42Nrj31bGv4uQWdavK7XAJwkweJQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=ovbz8iL4jahWrVdbP+FaT7kMbqk//UcVaeWL9Er6GK6MI4D1MMzHeG9REZpbSFxoli9bVJUZnUDeT058VOQUIyvgx28hTvWXRYNMmar64BXt8A0Fpl+c4rkMFxJQt4Mbw8LKAoL1/oKem0TRgWlBhMT95sDKGO7j1whugOLnSfM= 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=fLWbw0cL; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=D+UNdQf0; 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="fLWbw0cL"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="D+UNdQf0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1786110400; 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; bh=ryyH3WMM5bXwtJyWfdY/n49oHZTrsfyGZBILZcJ/9Sk=; b=fLWbw0cLUmchsWntoDmGVZssaquDLrMMvGBYDjrda2Kj5OvhoWeBesjGDpvToS5WoM6Zw3 76RBjUVh5Hjyao8jblF99HTA9CO/QIFoQqjJetq5EQHAaS23C0iMHN9hg7XGQp/yLfO2mZ EO0txVmjE+AZenKe/VPK8rE1ibCDqRs= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-358-pDWyouLSPSmsQmPWC8b8zw-1; Fri, 07 Aug 2026 09:46:37 -0400 X-MC-Unique: pDWyouLSPSmsQmPWC8b8zw-1 X-Mimecast-MFC-AGG-ID: pDWyouLSPSmsQmPWC8b8zw_1786110396 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-47162f83c75so1268287f8f.1 for ; Fri, 07 Aug 2026 06:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1786110396; x=1786715196; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=ryyH3WMM5bXwtJyWfdY/n49oHZTrsfyGZBILZcJ/9Sk=; b=D+UNdQf0mvpMwUgs1vqS2AlbkeO5rnbvV3DEByzYgApIpWNGu3faXsEpCHIsjAm0gK Ul0Pk3pfYcKaUgEX5YMNsdv2oFCXKFrWxwmlXtCOfLiewdPjQnmbpLrEjAMcSFdgG2om Tf3uW2xVQPUP4Km/vhdstLgRAGDN4glXj26LwjI9KYE2ZGbZkjpUXArOEGkyeIEih6Be ItaJw7Kb5qpfxBUKaJBXKUCjpm8ItC1Xz6rNfDha2JQE9OFRS5duqbV3eM1TJ7ggYTbr BuQihWOry+HZsx77ErZESfHn+yF+0GACE4yx9F/cMfs3cYYCjDEGXzduXAbcpbBUJfY7 DaTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786110396; x=1786715196; h=content-transfer-encoding:mime-version: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=ryyH3WMM5bXwtJyWfdY/n49oHZTrsfyGZBILZcJ/9Sk=; b=kRB6KYUDe1od1ShBrbvEIWuM0NQcYW4/ofXl2dSXA+pVq945McMmE4ku34x+yCu/v2 j+M9X9v9i/sngrBGf2sWZg5V3z/AlVmPALiHNWSRNL02pMMfucYZH4C+/kneH141W9sl ulO7wQx9ahca3L4eJG4IcnvaIq+7STYpqxAb6LbVVomhgpx+tgdtjMW1q+N/87c6QB7v YwlWblCflO8mRViAIV0U5F76UT4lPLV4xvJ3gq52ds2Jw+/Q4vHRanLkC/ZkXcLiedTL bCGb/BC6/srLXmYE81I1A0AXRAxNBJpa/7gg9Po6crK7KjV4PexomX1cDpLgIFL0SM72 vIkQ== X-Gm-Message-State: AOJu0YwmVhnGiiEoYLgBG0LFMhzoACE21TGvdRcuZnkcAYKDnURH3HbZ UZ7BNWrKul8sMclqVQc9u2yS/T3XJ/Xi//qSRn9zK58mDMUi0L5lLy3sT2uXkHlrQAEI1K6kqTC 3wM+Zf/i4NRBq2YDh+MYBBpmhQ7jz4ij6LucJ04Y3VLPXQaidUrzdnMd/20IGikaIAgQwIKP+xo cW+ac/0ZC4qVgwoxuHnvILE9fZ8Kg52U81u8gT3FLFJISTJuJJZQ== X-Gm-Gg: AR+sD10N9IfSJ7c9CwFWh13iwyoBfwouzk73GUtuPmsYzARuSYzx86Lt9johAOQGWhz U/iSO0Eqm04X5lvufNlyMel8aU+2eSHA3l1CwHBIJhrm9SSpnc15L16Dy+Z8oBbo78FvrJM8fiC 7ZR7rUaB5TvJ3eW190nafMSSNgrCXPiO1Hzv8ZZAYu9VNUFgUt4mWdA0ijgHfDytVoHzBkxqMrf u/SXJgz6ZyuiDjM/LmenAIOFCYupm2sA6IjyCSliaAdXCSZk0xnULU5PEjF8yjxXW2ux3o+Brq/ /dtbdxfi4g5x2s+cy3dnw7pbAk08UhC6ZJIALXHQEByn/DpU7OQMZhqmnZvgeQWo1cQLKtjYyDK 8cMB9QLY2/YsZB/R+/a+ErNbPy+T2C/iaUghWCxRlTYvko/nG39lvdncrSrQ0Z5RDzfK1GhYT8v MI1pc= X-Received: by 2002:a05:6000:4204:b0:47f:8603:a879 with SMTP id ffacd0b85a97d-48130b2ccfdmr187600f8f.11.1786110396400; Fri, 07 Aug 2026 06:46:36 -0700 (PDT) X-Received: by 2002:a05:6000:4204:b0:47f:8603:a879 with SMTP id ffacd0b85a97d-48130b2ccfdmr187464f8f.11.1786110395790; Fri, 07 Aug 2026 06:46:35 -0700 (PDT) Received: from [192.168.10.48] ([151.95.34.92]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-480021fd392sm5928108f8f.31.2026.08.07.06.46.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Aug 2026 06:46:35 -0700 (PDT) From: Paolo Bonzini To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Sean Christopherson , Hyunwoo Kim , stable@vger.kernel.org Subject: [PATCH] KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page Date: Fri, 7 Aug 2026 15:46:33 +0200 Message-ID: <20260807134633.2622273-1-pbonzini@redhat.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sean Christopherson Explicitly clear role.invalid when deriving a child shadow page's role from its parent to harden against bugs elsewhere in KVM, as violating KVM's invariant that invalid pages are NOT on the list of active MMU pages leads to use-after-free due to __kvm_mmu_prepare_zap_page() using list_add() instead of list_move() when processing an invalid shadow page, i.e. makes a bad situation far worse. Yell loudly if the parent is invalid, as it means KVM has missed a validity check, i.e. KVM is attempting to map memory using an invalid/obsolete root, but continue on as the child is otherwise still a valid shadow page. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BUG: KASAN: slab-use-after-free in __kvm_mmu_get_shadow_page+0x1817/0x186= 0 [kvm] Write of size 8 at addr ff11000153dd1368 by task repro/853 CPU: 1 UID: 1000 PID: 853 Comm: repro Not tainted 7.2.0-rc2-3aec122bdcaf-= next-vm #5 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4b/0x70 print_report+0x153/0x49c kasan_report+0xbc/0xf0 __kvm_mmu_get_shadow_page+0x1817/0x1860 [kvm] mmu_alloc_root+0x141/0x320 [kvm] kvm_mmu_load+0x612/0x20f0 [kvm] kvm_arch_vcpu_ioctl_run+0x3dd5/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Allocated by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x5f/0x70 kmem_cache_alloc_noprof+0xfe/0x2e0 __kvm_mmu_topup_memory_cache+0x135/0x530 [kvm] paging64_page_fault+0x318/0x1e30 [kvm] kvm_mmu_do_page_fault+0x21d/0x630 [kvm] kvm_mmu_page_fault+0x18c/0x17b0 [kvm] kvm_arch_vcpu_ioctl_run+0x1f35/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 853: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free+0xe2/0x400 kvm_mmu_commit_zap_page.part.0+0x1e2/0x310 [kvm] kvm_mmu_free_roots+0x283/0x560 [kvm] kvm_arch_vcpu_ioctl_run+0x33c8/0x6150 [kvm] kvm_vcpu_ioctl+0x5e4/0x10d0 [kvm] __x64_sys_ioctl+0x131/0x1b0 do_syscall_64+0x67/0x5f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Reported-by: Hyunwoo Kim Fixes: a770f6f28b1a ("KVM: MMU: Inherit a shadow page's guest level count f= rom vcpu setup") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini --- arch/x86/kvm/mmu/mmu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index c9e4739b26d7..a61750f8e1e3 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -2442,6 +2442,9 @@ static union kvm_mmu_page_role kvm_mmu_child_role(u64= *sptep, bool direct, role.direct =3D direct; role.passthrough =3D 0; =20 + WARN_ON_ONCE(role.invalid); + role.invalid =3D 0; + /* * If the guest has 4-byte PTEs then that means it's using 32-bit, * 2-level, non-PAE paging. KVM shadows such guests with PAE paging --=20 2.55.0