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

[Cyril Hrubis]

Hi!
> I guess something like this should be used:
> 
> 	for (unsigned int i = 0; i < 5000; i++) {
> 		TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> 							EINVAL);

It doesn't fail on older kernels, or did I misinterpret something? There
are three stable kernel trees based on kernels that are supposedly
affected, we do want to run this test for them too.

> 		if (!TST_PASS)
> 			return;
> 	}
> 
> 	tst_res(TPASS, "fsconfig() overflow on %s haven't triggerred crash",
> 			tst_device->fs_type);
> 
> but that fails on Btrfs.
> 
> > > +}
> > > +
> > > +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"},
> > > +		{}
> > > +	}
> 
> Results on my machine (6.2.0-rc6)
> 
> tst_test.c:1634: TINFO: === Testing on ext2 ===
> tst_test.c:1093: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
> mke2fs 1.46.5 (30-Dec-2021)
> note ext2 is *not* using new mount API
> fsconfig03.c:50: TPASS: fsconfig() overflow on ext2 haven't triggerred crash
> tst_test.c:1634: TINFO: === Testing on ext3 ===
> tst_test.c:1093: TINFO: Formatting /dev/loop0 with ext3 opts='' extra opts=''
> mke2fs 1.46.5 (30-Dec-2021)
> fsconfig03.c:50: TPASS: fsconfig() overflow on ext3 haven't triggerred crash
> tst_test.c:1634: TINFO: === Testing on ext4 ===
> tst_test.c:1093: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts=''
> mke2fs 1.46.5 (30-Dec-2021)
> fsconfig03.c:50: TPASS: fsconfig() overflow on ext4 haven't triggerred crash
> tst_test.c:1634: TINFO: === Testing on xfs ===
> tst_test.c:1093: TINFO: Formatting /dev/loop0 with xfs opts='' extra opts=''
> fsconfig03.c:50: TPASS: fsconfig() overflow on xfs haven't triggerred crash
> tst_test.c:1634: TINFO: === Testing on btrfs ===
> tst_test.c:1093: TINFO: Formatting /dev/loop0 with btrfs opts='' extra opts=''
> fsconfig03.c:44: TFAIL: fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0) succeeded
> Btrfs should be investigated (IMHO btrfs is using new mount API).
> 
> tst_test.c:1634: TINFO: === Testing on vfat ===
> tst_test.c:1093: TINFO: Formatting /dev/loop0 with vfat opts='' extra opts=''
> fsconfig03.c:44: TFAIL: fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0) succeeded
> 
> tst_test.c:1634: TINFO: === Testing on exfat ===
> tst_test.c:1093: TINFO: Formatting /dev/loop0 with exfat opts='' extra opts=''
> fsconfig03.c:50: TPASS: fsconfig() overflow on exfat haven't triggerred crash
> Interesting, exfat works :) It also uses new mount API.
> 
> 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)
> Hm, that's strange

ENODEV means that filesystem is not compiled in kernel, that's strage,
that would mean that you have a broken system, e.g. kernel modules that
support these filesystems are not installed properly or something like
that.

If you look at fs/filesystems.c the get_fs_type() function called from
the fsopen() uses the very same array that is used by the
/proc/filesystems we parse in LTP to get list of supported filesystems.

This is the place where you can get ENODEV:

https://elixir.bootlin.com/linux/latest/source/fs/fsopen.c#L132

And this is the place where it can fail:

https://elixir.bootlin.com/linux/latest/source/fs/filesystems.c#L261

> Due above, I suggest this:
> 	.skip_filesystems = (const char *const []){"ntfs", "vfat", NULL},


-- 
Cyril Hrubis
chrubis@suse.cz