Re: CVE Request - Linux kernel - securelevel/secureboot bypass.

[cve-assign () mitre org]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> When the kernel was booted with UEFI Secure Boot enabled, securelevel
> is set. If kexec (either through crash or admin action) is then used
> to load the same kernel, after reboot securelevel is disabled. In this
> state, the system is missing the protections provided by securelevel,
> for example kexec may be used to load an unsigned kernel via the
> legacy system call kexec_load.
>
> In the securelevel patchset, the state of UEFI Secure Boot is queried
> in the EFI stub, and sets a boot_params flag to indicate the state of
> UEFI Secure Boot. This flag is then used in setup_arch() to determine
> the correct state of securelevel. If the kernel is not booted via the
> EFI stub, securelevel is not set even if UEFI Secure Boot is enabled.
>
> TLDR: this allows a bypass the security mechanism of
> securelevel/secureboot combination.
>
> This patchset affects Red Hat specific kernels as secureboot is not
> fully fully implemented upstream yet.

As far as we can tell, you are reporting an issue in functionality
that was developed for a Red Hat product. Because identical
functionality is not currently offered elsewhere, a CVE ID can be
assigned without considering the details of the securelevel behavior
that may later be implemented (or considered optimal) outside of Red
Hat. In other words, within (at least) the Red Hat product, "If the
kernel is not booted via the EFI stub, securelevel is not set even if
UEFI Secure Boot is enabled" is unquestionably incorrect behavior.

Use CVE-2015-7837.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJWH9r7AAoJEL54rhJi8gl5TUkP/juU8uF2oSvn+q9wmrT0k7q1
zLxI2K9pxoryQq8EBSpQDelo97fe5QPAkQ/A1abN7kvNzSnfcLOvO9fW6KZyvOAY
Vc8qXf+3aQaGheqUWiuVnWTZtIbBvzLpVAiHIXhzYzz3bQ1SfXakdZVBum5d+X6U
cpZ2LYNUqV7RMJsM2cf/1XxeV7QHF0Q6QweyYWO4jZ9ijBVugEo+rK2uSFE5C3u5
8KSttFfEOJuAtfcPVZRUnrsc9cBON6VCJe0t+3dTrDJ3UQCPgOJda4AUKDzdQS3t
P9s24gZe5X+iquHonyLXNXiVbJS6CcSV9A0reYROwUMCI8/9tI5OezO65xraX1Q2
biO/KfO5iITCpFdf+EGH462P2LiNNpxx0ADJPxuxaABJhNS2NTCWer7y4OR6lbYN
16yWE3m4IfBhvoJjRPHoAHn/p+zzhPibnksyZbyPQJlj8Mw5ahYoAoaW5rBjmSTO
qu4RokLFIDbmdYyt9/6aXi6Y4rTobZ8MWdH+qjJu29e9SOT0aCU1qEzXA2TWqZtE
EwfwB2ZlP1XnmbBVBNMY9vuDdfEHFc3EABizcf/XwLr9t5sHJOg6GHbr3oln91T0
iAu3xAeWEEpyhqHANPx7x1pZTtgIfAdBofvsqHrKgP/Dj4MlXL29X2oO4nlnEsK4
xTCrWQkKNwm/ZzHYnYJW
=2iBw
-----END PGP SIGNATURE-----