Re: [ 058/184] KVM: x86: invalid opcode oops on SET_SREGS with

[Ben Hutchings]

On Tue, 2013-06-04 at 19:22 +0200, Willy Tarreau wrote:
> 2.6.32-longterm review patch.  If anyone has any objections, please let me know.
> 
> ------------------
>  OSXSAVE bit set (CVE-2012-4461)
> 
> From: Petr Matousek <pmatouse@xxxxxxxxxx>
> 
> commit 6d1068b3a98519247d8ba4ec85cd40ac136dbdf9 upstream.
> 
> On hosts without the XSAVE support unprivileged local user can trigger
> oops similar to the one below by setting X86_CR4_OSXSAVE bit in guest
> cr4 register using KVM_SET_SREGS ioctl and later issuing KVM_RUN
> ioctl.
> 
> invalid opcode: 0000 [#2] SMP
> Modules linked in: tun ip6table_filter ip6_tables ebtable_nat ebtables
> ...
> Pid: 24935, comm: zoog_kvm_monito Tainted: G      D      3.2.0-3-686-pae
> EIP: 0060:[<f8b9550c>] EFLAGS: 00210246 CPU: 0
> EIP is at kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm]
> EAX: 00000001 EBX: 000f387e ECX: 00000000 EDX: 00000000
> ESI: 00000000 EDI: 00000000 EBP: ef5a0060 ESP: d7c63e70
>  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> Process zoog_kvm_monito (pid: 24935, ti=d7c62000 task=ed84a0c0
> task.ti=d7c62000)
> Stack:
>  00000001 f70a1200 f8b940a9 ef5a0060 00000000 00200202 f8769009 00000000
>  ef5a0060 000f387e eda5c020 8722f9c8 00015bae 00000000 ed84a0c0 ed84a0c0
>  c12bf02d 0000ae80 ef7f8740 fffffffb f359b740 ef5a0060 f8b85dc1 0000ae80
> Call Trace:
>  [<f8b940a9>] ? kvm_arch_vcpu_ioctl_set_sregs+0x2fe/0x308 [kvm]
> ...
>  [<c12bfb44>] ? syscall_call+0x7/0xb
> Code: 89 e8 e8 14 ee ff ff ba 00 00 04 00 89 e8 e8 98 48 ff ff 85 c0 74
> 1e 83 7d 48 00 75 18 8b 85 08 07 00 00 31 c9 8b 95 0c 07 00 00 <0f> 01
> d1 c7 45 48 01 00 00 00 c7 45 1c 01 00 00 00 0f ae f0 89
> EIP: [<f8b9550c>] kvm_arch_vcpu_ioctl_run+0x92a/0xd13 [kvm] SS:ESP
> 0068:d7c63e70
> 
> QEMU first retrieves the supported features via KVM_GET_SUPPORTED_CPUID
> and then sets them later. So guest's X86_FEATURE_XSAVE should be masked
> out on hosts without X86_FEATURE_XSAVE, making kvm_set_cr4 with
> X86_CR4_OSXSAVE fail. Userspaces that allow specifying guest cpuid with
> X86_FEATURE_XSAVE even on hosts that do not support it, might be
> susceptible to this attack from inside the guest as well.
> 
> Allow setting X86_CR4_OSXSAVE bit only if host has XSAVE support.
> 
> Signed-off-by: Petr Matousek <pmatouse@xxxxxxxxxx>
> Signed-off-by: Marcelo Tosatti <mtosatti@xxxxxxxxxx>
> [bwh: Backported to 2.6.32: XSAVE is not supported at all, so always
>  deny setting OSXSAVE]

Signed-off-by: Ben Hutchings <ben@xxxxxxxxxxxxxxx>

> Signed-off-by: Willy Tarreau <w@xxxxxx>
> ---
>  arch/x86/kvm/x86.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 79905f2..ec9728f 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -4719,6 +4719,9 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
>  	int pending_vec, max_bits;
>  	struct descriptor_table dt;
>  
> +	if (sregs->cr4 & X86_CR4_OSXSAVE)
> +		return -EINVAL;
> +
>  	vcpu_load(vcpu);
>  
>  	dt.limit = sregs->idt.limit;

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
                                - John Levine, moderator of comp.compilers

Attachment: signature.asc
Description: This is a digitally signed message part