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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 Jan 2017 07:36:20 -0800
From:   Dave Hansen <>
Subject: Re: [tip:x86/urgent] x86/fpu: Set the xcomp_bv when we fake up a
 XSAVES area

On 01/23/2017 12:28 AM, tip-bot for Kevin Hao wrote:
> x86/fpu: Set the xcomp_bv when we fake up a XSAVES area
> I got the following calltrace on a Apollo Lake SoC with 32-bit kernel:

> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -1070,6 +1070,7 @@ int copyin_to_xsaves(const void *kbuf, const void __user *ubuf,
>  	 * Add back in the features that came in from userspace:
>  	 */
>  	xsave->header.xfeatures |= xfeatures;
> +	xsave->header.xcomp_bv = XCOMP_BV_COMPACTED_FORMAT | xsave->header.xfeatures;
>  	return 0;
>  }

First of all, thanks for finding this!  As you found, the 32-bit XSAVES
code is a bit light on testing.

I don't doubt that we have a code path that was screwed up like this,
but I don't think this is the right fix.

The kernel xsave buffer should *ALWAYS* have the
XCOMP_BV_COMPACTED_FORMAT bit set.  It should have been set before the
copyin and it should be set when it's finished.

The best fix here would be not to paper over the issue in the copy
function but find where it got clobbered, or where some initialization
code failed to set it.

Powered by blists - more mailing lists