From: Michael Ellerman <patch-notifications@ellerman.id.au>
To: Greg Kurz <groug@kaod.org>, Paul Mackerras <paulus@ozlabs.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
linuxppc-dev@lists.ozlabs.org,
Sean Christopherson <sean.j.christopherson@intel.com>,
kvm-ppc@vger.kernel.org
Subject: Re: [PATCH 1/3] KVM: PPC: Fix kernel crash with PR KVM
Date: Sat, 21 Mar 2020 11:37:52 +0000 [thread overview]
Message-ID: <48kzCh3rmzz9sSh@ozlabs.org> (raw)
In-Reply-To: <158455341029.178873.15248663726399374882.stgit@bahia.lan>
In-Reply-To: <158455341029.178873.15248663726399374882.stgit@bahia.lan>
On Wed, 2020-03-18 at 17:43:30 UTC, Greg Kurz wrote:
> With PR KVM, shutting down a VM causes the host kernel to crash:
>
> [ 314.219284] BUG: Unable to handle kernel data access on read at 0xc00800000176c638
> [ 314.219299] Faulting instruction address: 0xc008000000d4ddb0
> cpu 0x0: Vector: 300 (Data Access) at [c00000036da077a0]
> pc: c008000000d4ddb0: kvmppc_mmu_pte_flush_all+0x68/0xd0 [kvm_pr]
> lr: c008000000d4dd94: kvmppc_mmu_pte_flush_all+0x4c/0xd0 [kvm_pr]
> sp: c00000036da07a30
> msr: 900000010280b033
> dar: c00800000176c638
> dsisr: 40000000
> current = 0xc00000036d4c0000
> paca = 0xc000000001a00000 irqmask: 0x03 irq_happened: 0x01
> pid = 1992, comm = qemu-system-ppc
> Linux version 5.6.0-master-gku+ (greg@palmb) (gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #17 SMP Wed Mar 18 13:49:29 CET 2020
> enter ? for help
> [c00000036da07ab0] c008000000d4fbe0 kvmppc_mmu_destroy_pr+0x28/0x60 [kvm_pr]
> [c00000036da07ae0] c0080000009eab8c kvmppc_mmu_destroy+0x34/0x50 [kvm]
> [c00000036da07b00] c0080000009e50c0 kvm_arch_vcpu_destroy+0x108/0x140 [kvm]
> [c00000036da07b30] c0080000009d1b50 kvm_vcpu_destroy+0x28/0x80 [kvm]
> [c00000036da07b60] c0080000009e4434 kvm_arch_destroy_vm+0xbc/0x190 [kvm]
> [c00000036da07ba0] c0080000009d9c2c kvm_put_kvm+0x1d4/0x3f0 [kvm]
> [c00000036da07c00] c0080000009da760 kvm_vm_release+0x38/0x60 [kvm]
> [c00000036da07c30] c000000000420be0 __fput+0xe0/0x310
> [c00000036da07c90] c0000000001747a0 task_work_run+0x150/0x1c0
> [c00000036da07cf0] c00000000014896c do_exit+0x44c/0xd00
> [c00000036da07dc0] c0000000001492f4 do_group_exit+0x64/0xd0
> [c00000036da07e00] c000000000149384 sys_exit_group+0x24/0x30
> [c00000036da07e20] c00000000000b9d0 system_call+0x5c/0x68
>
> This is caused by a use-after-free in kvmppc_mmu_pte_flush_all()
> which dereferences vcpu->arch.book3s which was previously freed by
> kvmppc_core_vcpu_free_pr(). This happens because kvmppc_mmu_destroy()
> is called after kvmppc_core_vcpu_free() since commit ff030fdf5573
> ("KVM: PPC: Move kvm_vcpu_init() invocation to common code").
>
> The kvmppc_mmu_destroy() helper calls one of the following depending
> on the KVM backend:
>
> - kvmppc_mmu_destroy_hv() which does nothing (Book3s HV)
>
> - kvmppc_mmu_destroy_pr() which undoes the effects of
> kvmppc_mmu_init() (Book3s PR 32-bit)
>
> - kvmppc_mmu_destroy_pr() which undoes the effects of
> kvmppc_mmu_init() (Book3s PR 64-bit)
>
> - kvmppc_mmu_destroy_e500() which does nothing (BookE e500/e500mc)
>
> It turns out that this is only relevant to PR KVM actually. And both
> 32 and 64 backends need vcpu->arch.book3s to be valid when calling
> kvmppc_mmu_destroy_pr(). So instead of calling kvmppc_mmu_destroy()
> from kvm_arch_vcpu_destroy(), call kvmppc_mmu_destroy_pr() at the
> beginning of kvmppc_core_vcpu_free_pr(). This is consistent with
> kvmppc_mmu_init() being the last call in kvmppc_core_vcpu_create_pr().
>
> For the same reason, if kvmppc_core_vcpu_create_pr() returns an
> error then this means that kvmppc_mmu_init() was either not called
> or failed, in which case kvmppc_mmu_destroy() should not be called.
> Drop the line in the error path of kvm_arch_vcpu_create().
>
> Fixes: ff030fdf5573 ("KVM: PPC: Move kvm_vcpu_init() invocation to common code")
> Signed-off-by: Greg Kurz <groug@kaod.org>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/1d0c32ec3b860a32df593a22bad0d1dbc5546a59
cheers
next prev parent reply other threads:[~2020-03-21 11:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-18 17:43 [PATCH 0/3] KVM: PPC: Fix host kernel crash with PR KVM Greg Kurz
2020-03-18 17:43 ` [PATCH 1/3] KVM: PPC: Fix " Greg Kurz
2020-03-18 18:16 ` Sean Christopherson
2020-03-21 11:37 ` Michael Ellerman [this message]
2020-03-18 17:43 ` [PATCH 2/3] KVM: PPC: Move kvmppc_mmu_init() " Greg Kurz
2020-03-18 17:43 ` [PATCH 3/3] KVM: PPC: Kill kvmppc_ops::mmu_destroy() and kvmppc_mmu_destroy() Greg Kurz
2020-03-19 23:34 ` [PATCH 0/3] KVM: PPC: Fix host kernel crash with PR KVM Paul Mackerras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48kzCh3rmzz9sSh@ozlabs.org \
--to=patch-notifications@ellerman.id.au \
--cc=groug@kaod.org \
--cc=kvm-ppc@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@ozlabs.org \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox