Bugzilla – Bug 921027
VUL-1: CVE-2015-2672: kernel: xsaves / xrestors unhandled fault
Last modified: 2016-04-27 20:05:12 UTC
via mainline kernel git commit 06c8173eb92bbfc03a0fe8bb64315857d0badd06 From: Quentin Casasnovas <quentin.casasnovas@oracle.com> Date: Thu, 5 Mar 2015 13:19:22 +0100 Subject: x86/fpu/xsaves: Fix improper uses of __ex_table Commit: f31a9f7c7169 ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area") introduced alternative instructions for XSAVES/XRSTORS and commit: adb9d526e982 ("x86/xsaves: Add xsaves and xrstors support for booting time") added support for the XSAVES/XRSTORS instructions at boot time. Unfortunately both failed to properly protect them against faulting: The 'xstate_fault' macro will use the closest label named '1' backward and that ends up in the .altinstr_replacement section rather than in .text. This means that the kernel will never find in the __ex_table the .text address where this instruction might fault, leading to serious problems if userspace manages to trigger the fault.
(security impact not clear to me)
bugbot adjusting priority
did this turn more public now?
None of our trees is affected, closing.
public now From: Quentin Casasnovas <quentin.casasnovas@oracle.com> Subject: [oss-security] CVE Request: Linux kernel unprivileged denial-of-service due to mis-protected xsave/xrstor instructions. Date: Wed, 18 Mar 2015 11:14:05 +0100 Hi, Jamie and I discovered there was a flaw in the way the xsave/xrstor (and their alternative instructions) were being protected against a fault in kernel space from linux 3.15. The problem was introduced in commit f31a9f7 ("x86/xsaves: Use xsaves/xrstors to save and restore xsave area") which ends up protecting the .altinstr_replacement from faulting instead of the target of the alternative in .text, leaving the instruction un-protected. You can find a reproducer (thanks to Allan for his help with/comments on it!) triggering the fault in kernel space attached to this e-mail but it should be noted there are a few different places where these instructions are used un-protected and the reproducer only uses one of them present in the kvm code. You can find a list of all such places in the attached unprotected_xsave_faults attachment which was generated against a v4.0-rc1 defconfig + CONFIG_KVM vmlinux.o (the most concerning one probably being in __switch_to()). The reproducer is a patch to apply on top of lkvm (https://github.com/penberg/linux-kvm) but it should be trivial to write as a standalone C application. It should be noted that this vulnerability is present even if the hardware does not support xsaveS. This is fixed by upstream commit 06c8173eb: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit?id=06c8173eb92bbfc03a0fe8bb64315857d0badd06 Other patches to prevent introduction of the same class of vulnerability are currently being reviewed on lkml: https://lkml.org/lkml/2015/3/17/462 I haven't received any news from cve-assign when this issue was previously discussed on security@kernel.org. Could a CVE be assigned to this please? Thanks, Quentin
Created attachment 627393 [details] xsave-fault-reproducer.patch xsave-fault-reproducer.patch attached to email
Created attachment 627394 [details] unprotected_xsave_faults unprotected_xsave_faults attached to email