public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Wei Gao <wegao@suse.com>,
	Richard Palethorpe <rpalethorpe@suse.com>,
	ltp@lists.linux.it, Cyril Hrubis <chrubis@suse.cz>
Subject: Re: [LTP] [PATCH v2] fsconfig: New case cover CVE-2022-0185
Date: Thu, 9 Feb 2023 15:35:20 +0100	[thread overview]
Message-ID: <Y+UEqNtUTNaGVwXT@pevik> (raw)
In-Reply-To: <Y+UAENJVDUSDPAay@pevik>

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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  parent reply	other threads:[~2023-02-09 14:35 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-29 11:50 [LTP] [PATCH v1] fsconfig: New case cover CVE-2022-0185 Wei Gao via ltp
2023-02-01 12:49 ` Petr Vorel
2023-02-06 10:38   ` Wei Gao via ltp
2023-02-06 16:19     ` Petr Vorel
2023-02-08  9:01       ` Wei Gao via ltp
2023-02-08 15:48         ` Petr Vorel
2023-02-09  2:25           ` Wei Gao via ltp
2023-02-09 10:10             ` Cyril Hrubis
2023-02-09 11:37               ` Wei Gao via ltp
2023-02-06 16:42     ` Wei Gao via ltp
2023-02-09 13:19 ` [LTP] [PATCH v2] " Wei Gao via ltp
2023-02-09 14:15   ` Petr Vorel
2023-02-09 14:27     ` Cyril Hrubis
2023-02-09 14:40       ` Petr Vorel
2023-02-09 14:53         ` Cyril Hrubis
2023-02-09 14:35     ` Petr Vorel [this message]
2023-02-09 14:52       ` Cyril Hrubis
2023-02-09 15:18         ` Petr Vorel
2023-02-10  8:22         ` Wei Gao via ltp
2023-02-10  9:00           ` Wei Gao via ltp
2023-02-13  1:09   ` [LTP] [PATCH v3] fsconfig03: New test CVE-2022-0185 Wei Gao via ltp
2023-02-14 11:05     ` Richard Palethorpe
2023-02-16  9:42       ` Wei Gao via ltp
2023-02-16 12:09         ` Richard Palethorpe
2023-02-16 12:54           ` Wei Gao via ltp
2023-02-16 23:52     ` [LTP] [PATCH v4] " Wei Gao via ltp
2023-02-17  7:48       ` Petr Vorel
2023-02-17  8:47       ` Petr Vorel
2023-02-17  9:19         ` Wei Gao via ltp
2023-02-27 16:20       ` Richard Palethorpe
2023-02-28  3:22       ` [LTP] [PATCH v5] " Wei Gao via ltp
2023-02-28  3:27         ` [LTP] [PATCH v6] " Wei Gao via ltp
2023-02-28  8:49           ` Richard Palethorpe
2023-03-01 13:46           ` Martin Doucha
2023-03-01 14:12             ` Wei Gao via ltp
2023-03-02  1:45           ` [LTP] [PATCH v7] fsconfig03: SKIP check return value for old kernel Wei Gao via ltp
2023-03-02 10:00             ` Petr Vorel
2023-03-02 10:45               ` Wei Gao via ltp
2023-03-02 10:03             ` Petr Vorel
2023-03-04  2:03             ` [LTP] [PATCH v8] " Wei Gao via ltp
2023-03-07  9:23               ` Petr Vorel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+UEqNtUTNaGVwXT@pevik \
    --to=pvorel@suse.cz \
    --cc=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    --cc=rpalethorpe@suse.com \
    --cc=wegao@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox