[LTP] [PATCH v4] fsconfig03: New test CVE-2022-0185

[Richard Palethorpe]

Hello,

Wei Gao <wegao@suse.com> writes:

> There are reproducers available for CVE-2022-0185
> https://www.openwall.com/lists/oss-security/2022/01/25/14
>
> Also with links or even a zip file for an exploit
> https://github.com/Crusaders-of-Rust/CVE-2022-0185
>
> The exploits are kind of complicated as they try to be complete,
> but the exploitation vector is the fsconfig() syscall,
> this case used for add some coverage to that to detect it.
>
> When kernel < v5.15.16, you can easily reproduce crash use test case
> without check error and return logic in loop.
>
> I have used this test case trigger 5.14.1 kernel crash with ext2/4.
> Just make sure your kernel have not patched by following two commits:
> e192ccc17ecf3 - fix up param length parsing in legacy_parse_param
> cebe85d570cf8 - ext4: switch to the new mount api
>
> Signed-off-by: Wei Gao <wegao@suse.com>
> Reviewed-by: Petr Vorel <pvorel@suse.cz>
> Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>
> Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
> ---
>  runtest/cve                                   |  2 +
>  runtest/syscalls                              |  1 +
>  testcases/kernel/syscalls/fsconfig/.gitignore |  1 +
>  .../kernel/syscalls/fsconfig/fsconfig03.c     | 79 +++++++++++++++++++
>  4 files changed, 83 insertions(+)
>  create mode 100644 testcases/kernel/syscalls/fsconfig/fsconfig03.c
>
> diff --git a/runtest/cve b/runtest/cve
> index 1ba63c2a7..7da3ff853 100644
> --- a/runtest/cve
> +++ b/runtest/cve
> @@ -77,3 +77,5 @@ cve-2022-2590 dirtyc0w_shmem
>  # Tests below may cause kernel memory leak
>  cve-2020-25704 perf_event_open03
>  cve-2022-4378 cve-2022-4378
> +# Tests below may cause kernel crash
> +cve-2022-0185 fsconfig03
> diff --git a/runtest/syscalls b/runtest/syscalls
> index ae37a1192..b4cde8071 100644
> --- a/runtest/syscalls
> +++ b/runtest/syscalls
> @@ -383,6 +383,7 @@ fremovexattr02 fremovexattr02
>  
>  fsconfig01 fsconfig01
>  fsconfig02 fsconfig02
> +fsconfig03 fsconfig03
>  
>  fsmount01 fsmount01
>  fsmount02 fsmount02
> diff --git a/testcases/kernel/syscalls/fsconfig/.gitignore b/testcases/kernel/syscalls/fsconfig/.gitignore
> index 2bc54b827..cfedae5f7 100644
> --- a/testcases/kernel/syscalls/fsconfig/.gitignore
> +++ b/testcases/kernel/syscalls/fsconfig/.gitignore
> @@ -1,2 +1,3 @@
>  /fsconfig01
>  /fsconfig02
> +/fsconfig03
> diff --git a/testcases/kernel/syscalls/fsconfig/fsconfig03.c b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> new file mode 100644
> index 000000000..c2e908221
> --- /dev/null
> +++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2022 Alejandro Guerrero <aguerrero@...lys.com>
> + * Copyright (c) 2023 Wei Gao <wegao@suse.com>
> + */
> +
> +
> +/*\
> + * [Description]
> + *
> + * Test for CVE-2022-0185.
> + *
> + * References links:
> + * - https://www.openwall.com/lists/oss-security/2022/01/25/14
> + * - https://github.com/Crusaders-of-Rust/CVE-2022-0185
> + */
> +
> +#include "tst_test.h"
> +#include "lapi/fsmount.h"
> +
> +#define MNTPOINT	"mntpoint"
> +
> +static int fd = -1;
> +
> +static void setup(void)
> +{
> +	fsopen_supported_by_kernel();
> +}
> +
> +static void run(void)
> +{
> +	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
> +	long pagesize;
> +
> +	TEST(fd = fsopen(tst_device->fs_type, 0));
> +	if (fd == -1)
> +		tst_brk(TBROK | TTERRNO, "fsopen() failed");
> +
> +	pagesize = sysconf(_SC_PAGESIZE);
> +	if (pagesize == -1)
> +		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
> +
> +	for (size_t i = 0; i < 5000; i++) {
> +		/* use same logic in kernel legacy_parse_param function */
> +		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
> +
> +		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize) {
> +			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> +			if (TST_ERR)
> +				return;

Why not keep going if there is an error? Possibly we won't get an Ooops
the first time there is an error, but if we keep going then it will
result in a more serious error. Perhaps in this case it is unlikely, but
I don't see a big downside to keep going.

Generally people pay more attention to stack traces.

> +		} else {
> +			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> +					    EINVAL);
> +			if (!TST_PASS)
> +				return;

Same here.

I know it will result in 1000's of lines of noise, but only in the
failure case.

> +		}
> +	}
> +
> +	if (fd != -1)
> +		SAFE_CLOSE(fd);
> +
> +	tst_res(TPASS, "fsconfig() overflow on %s haven't triggerred crash",
> +			tst_device->fs_type);

It's OK to print pass after printing fail if the pass and fail messages
do not contradict each other.

Actually I now remember that we can check for kernel taints, from the
manual:

1.24 Tainted kernels
~~~~~~~~~~~~~~~~~~~~

If you need to detect whether a testcase triggers a kernel warning, bug or
oops, the following can be used to detect TAINT_W or TAINT_D:

[source,c]
-------------------------------------------------------------------------------
#include "tst_test.h"

static struct tst_test test = {
	...
	.taint_check = TST_TAINT_W | TST_TAINT_D,
	...
};

void run(void)
{
	...
	if (tst_taint_check() != 0)
		tst_res(TFAIL, "kernel has issues");
	else
		tst_res(TPASS, "kernel seems to be fine");
}
-------------------------------------------------------------------------------

...

If fsconfig produces an unexpected result, but there is no Oops this is
usefull for debugging. Especially if it is just the test that is broken.

> +}
> +
> +static struct tst_test test = {
> +	.test_all = run,
> +	.setup = setup,
> +	.needs_root = 1,
> +	.format_device = 1,
> +	.mntpoint = MNTPOINT,
> +	.all_filesystems = 1,
> +	.skip_filesystems = (const char *const []){"ntfs", "vfat", NULL},
> +	.tags = (const struct tst_tag[]) {
> +		{"linux-git", "722d94847de29"},
> +		{"CVE", "2022-0185"},
> +		{}
> +	}
> +};


-- 
Thank you,
Richard.