On Mon, Sep 23, 2019 at 05:43:48PM +0200, Greg Kurz wrote: > We currently prevent userspace to connect a new vCPU if we already have > one with the same vCPU id. This is good but unfortunately not enough, > because VP ids derive from the packed vCPU ids, and kvmppc_pack_vcpu_id() > can return colliding values. For examples, 348 stays unchanged since it > is < KVM_MAX_VCPUS, but it is also the packed value of 2392 when the > guest's core stride is 8. Nothing currently prevents userspace to connect > vCPUs with forged ids, that end up being associated to the same VP. This > confuses the irq layer and likely crashes the kernel: > > [96631.670454] genirq: Flags mismatch irq 4161. 00010000 (kvm-1-2392) vs. 00010000 (kvm-1-348) Have you seen a host kernel crash? How hard would it be to exploit this, and would it just be a denial of service, or do you think it could be used to get a use-after-free in the kernel or something like that? Also, does this patch depend on the patch 2 in this series? Paul.
