All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.