[LTP] [PATCH] syscalls/request_key03: new test for key instantiation races

Petr Vorel pvorel@suse.cz
Tue Oct 31 09:25:43 CET 2017


> From: Eric Biggers <ebiggers@google.com>

> Add a test for two related bugs in the keyrings subsystem which each
> allowed unprivileged local users to cause a kernel oops (at best) by
> attempting to "add" a key concurrently with "requesting" it.

> Signed-off-by: Eric Biggers <ebiggers@google.com>

Looks very nice to me. Just two notes below.

<snip>

> +
> +	SAFE_WAITPID(add_key_pid, &status, 0);
> +	if (WIFEXITED(status) && WEXITSTATUS(status) == 0) {
> +		tst_res(TPASS, "didn't crash while updating key of type '%s'",
> +			type);
> +	} else if (WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL) {
> +		/* Probably CVE-2017-15299 */
> +		tst_res(TFAIL, "kernel oops while updating key of type '%s'",
> +			type);
> +	} else {
> +		tst_brk(TBROK, "add_key child %s", tst_strstatus(status));
> +	}
> +
> +	SAFE_WAITPID(request_key_pid, &status, 0);
> +	if (WIFEXITED(status) && WEXITSTATUS(status) == 0) {
> +		tst_res(TPASS, "didn't crash while requesting key of type '%s'",
> +			type);
> +	} else if (WIFSIGNALED(status) && WTERMSIG(status) == SIGKILL) {
> +		/* Probably CVE-2017-15951 */
> +		tst_res(TFAIL, "kernel oops while requesting key of type '%s'",
> +			type);
> +	} else {
> +		tst_brk(TBROK, "request_key child %s", tst_strstatus(status));
> +	}

You evaluate test twice: for add_key_pid and then for request_key_pid.
This can lead to FAIL and PASS together. It's probably ok, it's just unusual for me.
./request_key03 
tst_test.c:958: INFO: Timeout per run is 0h 05m 00s
request_key03.c:136: FAIL: kernel oops while updating key of type 'encrypted'
request_key03.c:144: PASS: didn't crash while requesting key of type 'encrypted'
...


> +static void do_test(void)
> +{
> +	/*
> +	 * Briefly test the "encrypted" and/or "trusted" key types when
> +	 * availaible, mainly to reproduce CVE-2017-15299.
> +	 */
> +	test_with_key_type("encrypted", "update user:foo 32", 2);
> +	test_with_key_type("trusted", "update", 2);
> +
> +	/*
> +	 * Test the "user" key type for longer, mainly in order to reproduce
> +	 * CVE-2017-15951.  However, without the fix for CVE-2017-15299 as well,
> +	 * WARNs may show up in the kernel log.
> +	 */
> +	test_with_key_type("user", "payload", 15);
I wonder (out of curiosity how did you get values for effort (2 and 15).

<snip>

Kind regards,
Petr


More information about the ltp mailing list