| Message ID | 20230209131902.12260-1-wegao@suse.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | [v2] fsconfig: New case cover CVE-2022-0185 | expand |
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"},
> + {}
> + }
> +};
Hi! > > +static void run(void) > > +{ > > + char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; > > + > > + for (unsigned int i = 0; i < 5000; i++) > > + TEST(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0)); Also as far as I understand the discussion fsconfig() returns EINVAL on new enough kernels here, right? If that is the case we should also check that the call fails properly from the v5.17 and newer.
Hi Wei, ... > > +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)); TEST() itself does nothing. > > + > > + tst_res(TPASS | TTERRNO, "Try fsconfig overflow on %s done! Failed as expected", tst_device->fs_type); TTERRNO should not be used with TPASS, TPASS does not analyze anything. 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); 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 Due above, I suggest this: .skip_filesystems = (const char *const []){"ntfs", "vfat", NULL}, Kind regards, Petr
> Hi! > > > +static void run(void) > > > +{ > > > + char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; > > > + > > > + for (unsigned int i = 0; i < 5000; i++) > > > + TEST(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0)); > Also as far as I understand the discussion fsconfig() returns EINVAL on > new enough kernels here, right? If that is the case we should also check > that the call fails properly from the v5.17 and newer. I'd test all kernels and expect them to return EINVAL. Because 722d94847de29 was backported to 5.10.x and 5.4.x stable kernels. It'd be worth to check how it behaves on older stable (e.g. 4.19.x) and either raise .min_kernel lower than 5.4 if easily modified behavior for older kernels or ask for 5.4 otherwise. (I mean .min_kver = "5.17", is too aggressive). Kind regards, Petr
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},
Hi! > I'd test all kernels and expect them to return EINVAL. > Because 722d94847de29 was backported to 5.10.x and 5.4.x stable kernels. > It'd be worth to check how it behaves on older stable (e.g. 4.19.x) and either > raise .min_kernel lower than 5.4 if easily modified behavior for older kernels > or ask for 5.4 otherwise. (I mean .min_kver = "5.17", is too aggressive). As long as the backported fix causes fsopen() to return EINVAL we should check for it as well.
... > > 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. IT fails on new (fixed) kernels (tested on 6.2.0-rc6), it's about test does not crash anything).
On Thu, Feb 09, 2023 at 03:52:37PM +0100, Cyril Hrubis wrote: > Hi! > > 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}, > Result in my machine 6.0.0-rc5, the ntfs check no failed with ENODEV but show succeeded when do fsconfig. I will do further check on btrfs why it show success, will notify you once i got result. tst_test.c:1634: TINFO: === Testing on ext2 === tst_test.c:1093: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts='' mke2fs 1.46.6 (1-Feb-2023) 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.6 (1-Feb-2023) 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.6 (1-Feb-2023) fsconfig03.c:50: TPASS: fsconfig() overflow on ext4 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 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 ntfs === tst_test.c:1093: TINFO: Formatting /dev/loop0 with ntfs opts='' extra opts='' Failed to set locale, using default 'C'. 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:44: TFAIL: fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0) succeeded tst_test.c:1634: TINFO: === Testing on tmpfs === tst_test.c:1093: TINFO: Skipping mkfs for TMPFS filesystem > > -- > Cyril Hrubis > chrubis@suse.cz
On Fri, Feb 10, 2023 at 03:22:08AM -0500, Wei Gao via ltp wrote: > On Thu, Feb 09, 2023 at 03:52:37PM +0100, Cyril Hrubis wrote: > > Hi! > > > > 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}, > > > > Result in my machine 6.0.0-rc5, the ntfs check no failed with ENODEV but show succeeded when do fsconfig. > I will do further check on btrfs why it show success, will notify you once i got result. > > > tst_test.c:1634: TINFO: === Testing on ext2 === > tst_test.c:1093: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts='' > mke2fs 1.46.6 (1-Feb-2023) > 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.6 (1-Feb-2023) > 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.6 (1-Feb-2023) > fsconfig03.c:50: TPASS: fsconfig() overflow on ext4 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 > 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 ntfs === > tst_test.c:1093: TINFO: Formatting /dev/loop0 with ntfs opts='' extra opts='' > Failed to set locale, using default 'C'. > 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:44: TFAIL: fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0) succeeded > tst_test.c:1634: TINFO: === Testing on tmpfs === > tst_test.c:1093: TINFO: Skipping mkfs for TMPFS filesystem > I have no idea why btrfs still not set .init_fs_context even for kernel 6.0, so it will go legacy handle function which can not return error in our test case. So if we need extra test logic for btrfs. static struct file_system_type btrfs_fs_type = { .owner = THIS_MODULE, .name = "btrfs", .mount = btrfs_mount, .kill_sb = btrfs_kill_super, .fs_flags = FS_REQUIRES_DEV | FS_BINARY_MOUNTDATA, }; static struct file_system_type btrfs_root_fs_type = { .owner = THIS_MODULE, .name = "btrfs", .mount = btrfs_mount_root, .kill_sb = btrfs_kill_super, .fs_flags = FS_REQUIRES_DEV | FS_BINARY_MOUNTDATA | FS_ALLOW_IDMAP, }; > > > > -- > > Cyril Hrubis > > chrubis@suse.cz > > -- > Mailing list info: https://lists.linux.it/listinfo/ltp
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..32d062f66 --- /dev/null +++ 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> + */ + +/*\ + * [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 + */ + +#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)); + + 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", + .tags = (const struct tst_tag[]) { + {"linux-git", "722d94847de29"}, + {"CVE", "2020-29373"}, + {"CVE", "2022-0185"}, + {} + } +};
There are reproducers available for CVE-2022-0185 https://www.openwall.com/lists/oss-security/2022/01/25/14 has 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. Signed-off-by: Wei Gao <wegao@suse.com> --- runtest/syscalls | 1 + testcases/kernel/syscalls/fsconfig/.gitignore | 1 + .../kernel/syscalls/fsconfig/fsconfig03.c | 64 +++++++++++++++++++ 3 files changed, 66 insertions(+) create mode 100644 testcases/kernel/syscalls/fsconfig/fsconfig03.c