lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 11 Jan 2021 15:01:06 -0800 From: Sean Christopherson <seanjc@...gle.com> To: Jim Mattson <jmattson@...gle.com> Cc: syzbot <syzbot+e87846c48bf72bc85311@...kaller.appspotmail.com>, Borislav Petkov <bp@...en8.de>, "H . Peter Anvin" <hpa@...or.com>, Joerg Roedel <joro@...tes.org>, kvm list <kvm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>, Paolo Bonzini <pbonzini@...hat.com>, syzkaller-bugs <syzkaller-bugs@...glegroups.com>, Thomas Gleixner <tglx@...utronix.de>, Vitaly Kuznetsov <vkuznets@...hat.com>, Wanpeng Li <wanpengli@...cent.com>, the arch/x86 maintainers <x86@...nel.org> Subject: Re: UBSAN: shift-out-of-bounds in kvm_vcpu_after_set_cpuid On Mon, Jan 11, 2021, Jim Mattson wrote: > It looks like userspace can possibly induce this by providing guest > CPUID information with a "physical address width" of 64 in leaf > 0x80000008. It was actually the opposite, where userspace provides '0' and caused '63 - 0 + 1' to overflow. KVM controls the upper bound, and rsvd_bits() explicitly handles 'end < start', so an absurdly large maxpa is handled correctly. Aleady fixed by Paolo in commit 2f80d502d627 ("KVM: x86: fix shift out of bounds reported by UBSAN"). > Perhaps cpuid_query_maxphyaddr() should just look at the low 5 bits of > CPUID.80000008H:EAX? Better would be to return an error for > out-of-range values, but I understand that the kvm community's stance > is that, in general, guest CPUID information should not be validated > by kvm. And rob Paolo of his crazy^Wbrilliant bit math shenanigans? :-D
Powered by blists - more mailing lists