[LTP] [PATCH v2] fsconfig: New case cover CVE-2022-0185

[Petr Vorel]

Hi Wei,

There is still problem with ntfs:

tst_test.c:1634: TINFO: === Testing on ntfs ===
tst_test.c:1093: TINFO: Formatting /dev/loop0 with ntfs opts='' extra opts=''
The partition start sector was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of sectors per track was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
The number of heads was not specified for /dev/loop0 and it could not be obtained automatically.  It has been set to 0.
To boot from a device, Windows needs the 'partition start sector', the 'sectors per track' and the 'number of heads' to be set.
Windows will not be able to boot from this device.
fsconfig03.c:29: TBROK: fsopen() failed: ENODEV (19)

Therefore I'd skip it:
.skip_filesystems = (const char *const []){"ntfs", NULL},

> There are reproducers available for CVE-2022-0185
> https://www.openwall.com/lists/oss-security/2022/01/25/14

nit: I'd also change the commit message subject (i.e. first line) to something like
"fsconfig03: New test CVE-2022-0185"

(have taht 03)

> has links or even a zip file for an exploit
> https://github.com/Crusaders-of-Rust/CVE-2022-0185
nit: also add blank line here (readability).

> 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.

> Signed-off-by: Wei Gao <wegao@suse.com>
...
> +++ b/runtest/syscalls
> @@ -383,6 +383,7 @@ fremovexattr02 fremovexattr02

>  fsconfig01 fsconfig01
>  fsconfig02 fsconfig02
> +fsconfig03 fsconfig03

There should be *also* entry in runtest/cve:
CVE-2022-0185 fsconfig03

...
> +++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> @@ -0,0 +1,64 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2023 Wei Gao <wegao@suse.com>
If you used code from elsewhere (although rewritten), you should add the
copyright of the author.
> + */
> +
> +/*\
> + * [Description]
> + *
> + * Test add some coverage to CVE-2022-0185.
> + * Try to trigger a crash.
> + * References links:
> + * https://www.openwall.com/lists/oss-security/2022/01/25/14
> + * https://github.com/Crusaders-of-Rust/CVE-2022-0185
> + */

I suggest something like this (you would understand me if you had run 'cd
metadata && make' and then had ../looked at resulted ../docparse/metadata.html):

 /*\
  * [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();
> +
> +	TEST(fd = fsopen(tst_device->fs_type, 0));
> +	if (fd == -1)
> +		tst_brk(TBROK | TTERRNO, "fsopen() failed");
> +
> +}
> +
> +static void cleanup(void)
> +{
> +	if (fd != -1)
> +		SAFE_CLOSE(fd);
> +}
> +
> +static void run(void)
> +{
> +	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
> +
> +	for (unsigned int i = 0; i < 5000; i++)
> +		TEST(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));

@Richie, interesting, make check cannot detect FSCONFIG_SET_STRING
(from <linux/mount.h> or <sys/mount.h>):
CHECK testcases/kernel/syscalls/fsconfig/fsconfig03.c
fsconfig03.c:44:17: error: undefined identifier 'FSCONFIG_SET_STRING'

> +
> +	tst_res(TPASS | TTERRNO, "Try fsconfig overflow on %s done! Failed as expected", tst_device->fs_type);
> +}
> +
> +static struct tst_test test = {
> +	.test_all = run,
> +	.setup = setup,
> +	.cleanup = cleanup,
> +	.needs_root = 1,
> +	.format_device = 1,
> +	.mntpoint = MNTPOINT,
> +	.all_filesystems = 1,
> +	.min_kver = "5.17",
You probably add it because 722d94847de29 comes from 5.17-rc1, but that should
go away, because this fix has been backported to (at least) sles kernels (which
are older).

> +	.tags = (const struct tst_tag[]) {
> +		{"linux-git", "722d94847de29"},
> +		{"CVE", "2020-29373"},
IMHO CVE-2020-29373 is about io_uring
https://nvd.nist.gov/vuln/detail/CVE-2020-29373
Does it really belong to this test? If yes, it has another kernel fix.
And you don't mention it in docparse description.

> +		{"CVE", "2022-0185"},
> +		{}
> +	}
> +};