On 10/04/15 17:43, Paolo Bonzini wrote: > > > On 10/04/2015 17:25, Marc Zyngier wrote: >> On 10/04/15 16:17, Andre Przywara wrote: >>> When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently >>> only check it against a fixed limit, which historically is set >>> to 127. With the new dynamic IRQ allocation the effective limit may >>> actually be smaller (64). >>> So when now a malicious or buggy userland injects a SPI in that >>> range, we spill over on our VGIC bitmaps and bytemaps memory. >>> I could trigger a host kernel NULL pointer dereference with current >>> mainline by injecting some bogus IRQ number from a hacked kvmtool: >>> ----------------- >>> .... >>> DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1) >>> DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1) >>> DEBUG: IRQ #114 still in the game, writing to bytemap now... >>> Unable to handle kernel NULL pointer dereference at virtual address 00000000 >>> pgd = ffffffc07652e000 >>> [00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000 >>> Internal error: Oops: 96000006 [#1] PREEMPT SMP >>> Modules linked in: >>> CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027 >>> Hardware name: FVP Base (DT) >>> task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000 >>> PC is at kvm_vgic_inject_irq+0x234/0x310 >>> LR is at kvm_vgic_inject_irq+0x30c/0x310 >>> pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145 >>> ..... >>> >>> So this patch fixes this by checking the SPI number against the >>> actual limit. Also we remove the former legacy hard limit of >>> 127 in the ioctl code. >>> >>> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx> >>> CC: <stable@xxxxxxxxxxxxxxx> # 4.0, 3.19, 3.18 >> >> Reviewed-by: Marc Zyngier <marc.zyngier@xxxxxxx> >> >> It is getting really tight for 4.0, but hopefully I can squeeze it in a >> second pull request together with the missing barrier on 32bit. > > I doubt I'll be able to send the pull request to Linus. Can't it really > wait a couple of weeks? I'll include it in the second pull request for > 4.1, together with (if you want) the lazy (lazier) FP/SIMD save/restore. That's what I meant (sorry if I wasn't clear). Second PR for 4.1 is just fine, we'll Cc stable anyway. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
