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

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

[Wei Gao via ltp]

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>
---
 include/lapi/fsmount.h                        |  5 +-
 runtest/syscalls                              |  1 +
 .../kernel/syscalls/fsconfig/fsconfig03.c     | 58 +++++++++++++++++++
 3 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 testcases/kernel/syscalls/fsconfig/fsconfig03.c

diff --git a/include/lapi/fsmount.h b/include/lapi/fsmount.h
index 07eb42ffa..252accb0f 100644
--- a/include/lapi/fsmount.h
+++ b/include/lapi/fsmount.h
@@ -11,12 +11,15 @@
 #include "config.h"
 #include <sys/syscall.h>
 #include <sys/types.h>
-#include <sys/mount.h>
 
 #ifndef HAVE_FSOPEN
 # ifdef HAVE_LINUX_MOUNT_H
 #  include <linux/mount.h>
+# else
+#  include <sys/mount.h>
 # endif
+#else
+# include <sys/mount.h>
 #endif
 
 #include "lapi/fcntl.h"
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/fsconfig03.c b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
new file mode 100644
index 000000000..e076c2f09
--- /dev/null
+++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2023 Wei Gao <wegao@suse.com>
+ */
+
+/*\
+ * 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 < 2; i++) {
+		TEST(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
+		if (TST_RET == -1)
+			tst_brk(TFAIL | TTERRNO, "fsconfig(FSCONFIG_SET_STRING) failed");
+	}
+	tst_res(TPASS, "Try fsconfig overflow on %s done!", 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,
+	.skip_filesystems = (const char *const []){"fuse", "ext2", "xfs", "tmpfs", NULL},
+};
-- 
2.35.3


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

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

[Petr Vorel]

Hi Wei,

...
> +++ b/include/lapi/fsmount.h
> @@ -11,12 +11,15 @@
>  #include "config.h"
>  #include <sys/syscall.h>
>  #include <sys/types.h>
> -#include <sys/mount.h>

>  #ifndef HAVE_FSOPEN
>  # ifdef HAVE_LINUX_MOUNT_H
>  #  include <linux/mount.h>
> +# else
> +#  include <sys/mount.h>
>  # endif
> +#else
> +# include <sys/mount.h>
>  #endif
Does <linux/mount.h> conflicts with <sys/mount.h>? Or why is this needed?

>  #include "lapi/fcntl.h"
> 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

NOTE: you also need to add a new record in testcases/kernel/syscalls/fsconfig/.gitignore.

> diff --git a/testcases/kernel/syscalls/fsconfig/fsconfig03.c b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> new file mode 100644
> index 000000000..e076c2f09
> --- /dev/null
> +++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> @@ -0,0 +1,58 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2023 Wei Gao <wegao@suse.com>
> + */
> +
> +/*\
NOTE, there should be docparse label:
 * [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");
Sooner or later we should add SAFE_FSOPEN(), but that can wait.

> +
> +}
> +
> +static void cleanup(void)
> +{
> +	if (fd != -1)
> +		SAFE_CLOSE(fd);
> +}
> +
> +static void run(void)
> +{
> +	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
> +
> +	for (unsigned int i = 0; i < 2; i++) {
> +		TEST(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> +		if (TST_RET == -1)
> +			tst_brk(TFAIL | TTERRNO, "fsconfig(FSCONFIG_SET_STRING) failed");
TST_EXP_PASS() or other could here be used (it should be changes also in fsconfig01.c).

Hm, there is a kernel fix from 5.17 [1]. But test fails when I run it on 6.2.0-rc5:

tst_supported_fs_types.c:165: TINFO: Skipping FUSE based ntfs as requested by the test
tst_supported_fs_types.c:157: TINFO: Skipping tmpfs as requested by the test
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:44: TFAIL: fsconfig(FSCONFIG_SET_STRING) failed: EINVAL (22)

Isn't it the opposite: we expect to fail, thus TST_EXP_FAIL() should here be
used?

> +	}
> +	tst_res(TPASS, "Try fsconfig overflow on %s done!", 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,
> +	.skip_filesystems = (const char *const []){"fuse", "ext2", "xfs", "tmpfs", NULL},

I wonder why this is should not be run on XFS and ext2.

Also, while we have CVE and kernel fix [1], it should be marked in struct tst_test:

	.tags = (const struct tst_tag[]) {
		{"linux-git", "722d94847de2"},
		{"CVE", "2020-29373"},
		{"CVE", "2022-0185"},
		{}
	}

Kind regards,
Petr

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=722d94847de2


> +};

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

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

[Wei Gao via ltp]

On Wed, Feb 01, 2023 at 01:49:43PM +0100, Petr Vorel wrote:
> Hi Wei,
> 
> ...
> > +++ b/include/lapi/fsmount.h
> > @@ -11,12 +11,15 @@
> >  #include "config.h"
> >  #include <sys/syscall.h>
> >  #include <sys/types.h>
> > -#include <sys/mount.h>
> 
> >  #ifndef HAVE_FSOPEN
> >  # ifdef HAVE_LINUX_MOUNT_H
> >  #  include <linux/mount.h>
> > +# else
> > +#  include <sys/mount.h>
> >  # endif
> > +#else
> > +# include <sys/mount.h>
> >  #endif
> Does <linux/mount.h> conflicts with <sys/mount.h>? Or why is this needed?
> 
> >  #include "lapi/fcntl.h"
> > 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
> 
> NOTE: you also need to add a new record in testcases/kernel/syscalls/fsconfig/.gitignore.
> 
> > diff --git a/testcases/kernel/syscalls/fsconfig/fsconfig03.c b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> > new file mode 100644
> > index 000000000..e076c2f09
> > --- /dev/null
> > +++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> > @@ -0,0 +1,58 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (c) 2023 Wei Gao <wegao@suse.com>
> > + */
> > +
> > +/*\
> NOTE, there should be docparse label:
>  * [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");
> Sooner or later we should add SAFE_FSOPEN(), but that can wait.
> 
> > +
> > +}
> > +
> > +static void cleanup(void)
> > +{
> > +	if (fd != -1)
> > +		SAFE_CLOSE(fd);
> > +}
> > +
> > +static void run(void)
> > +{
> > +	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
> > +
> > +	for (unsigned int i = 0; i < 2; i++) {
> > +		TEST(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> > +		if (TST_RET == -1)
> > +			tst_brk(TFAIL | TTERRNO, "fsconfig(FSCONFIG_SET_STRING) failed");
> TST_EXP_PASS() or other could here be used (it should be changes also in fsconfig01.c).
> 
> Hm, there is a kernel fix from 5.17 [1]. But test fails when I run it on 6.2.0-rc5:
> 
> tst_supported_fs_types.c:165: TINFO: Skipping FUSE based ntfs as requested by the test
> tst_supported_fs_types.c:157: TINFO: Skipping tmpfs as requested by the test
> 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:44: TFAIL: fsconfig(FSCONFIG_SET_STRING) failed: EINVAL (22)
> 
> Isn't it the opposite: we expect to fail, thus TST_EXP_FAIL() should here be
> used?
> 
I have not test on 6.2.0 kernel, i need reproduce this firstly.
> > +	}
> > +	tst_res(TPASS, "Try fsconfig overflow on %s done!", 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,
> > +	.skip_filesystems = (const char *const []){"fuse", "ext2", "xfs", "tmpfs", NULL},
> 
> I wonder why this is should not be run on XFS and ext2.
ext2: this if failed on one of my specific machine, so normally this should run.
xfs: this always error happen with error code "TFAIL: fsconfig(FSCONFIG_SET_STRING) failed: EINVAL (22)", i 
need debug kernel to check what's happen.
> 
> Also, while we have CVE and kernel fix [1], it should be marked in struct tst_test:
> 
> 	.tags = (const struct tst_tag[]) {
> 		{"linux-git", "722d94847de2"},
> 		{"CVE", "2020-29373"},
> 		{"CVE", "2022-0185"},
> 		{}
> 	}
> 
> Kind regards,
> Petr
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=722d94847de2
> 
> 
> > +};

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

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

[Petr Vorel]

Hi Wei,

...
> > Hm, there is a kernel fix from 5.17 [1]. But test fails when I run it on 6.2.0-rc5:

> > tst_supported_fs_types.c:165: TINFO: Skipping FUSE based ntfs as requested by the test
> > tst_supported_fs_types.c:157: TINFO: Skipping tmpfs as requested by the test
> > 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:44: TFAIL: fsconfig(FSCONFIG_SET_STRING) failed: EINVAL (22)

> > Isn't it the opposite: we expect to fail, thus TST_EXP_FAIL() should here be
> > used?

> I have not test on 6.2.0 kernel, i need reproduce this firstly.

FYI 6.0.6 is also broken, works on 5.10.46.

Kind regards,
Petr

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

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

[Wei Gao via ltp]

On Mon, Feb 06, 2023 at 05:19:53PM +0100, Petr Vorel wrote:
> Hi Wei,
> 
> ...
> > > Hm, there is a kernel fix from 5.17 [1]. But test fails when I run it on 6.2.0-rc5:
> 
> > > tst_supported_fs_types.c:165: TINFO: Skipping FUSE based ntfs as requested by the test
> > > tst_supported_fs_types.c:157: TINFO: Skipping tmpfs as requested by the test
> > > 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:44: TFAIL: fsconfig(FSCONFIG_SET_STRING) failed: EINVAL (22)
> 
> > > Isn't it the opposite: we expect to fail, thus TST_EXP_FAIL() should here be
> > > used?
> 
> > I have not test on 6.2.0 kernel, i need reproduce this firstly.
> 
> FYI 6.0.6 is also broken, works on 5.10.46.
> 

After long investigation i finally get what's happen now since i have
never touch kernel fs code before :)

The root caused is cebe85d570cf8 which make udpate initialize of
ext3_fs_type.

Each file system will initialize a struct file_system_type and ext3 initialize 
in fs/ext4/super.c(maybe ext3 much same as ext4 so they put in same file).
This patch add new memeber .init_fs_context in ext3 file_system_type struct and 
this new member will lead pase function which called by fsconfig change
from legacy_parse_param to ext4_parse_param(this function will check
parameter and not allow 0x00)

===key change part of cebe85d570cf8===
 static struct file_system_type ext3_fs_type = {
-       .owner          = THIS_MODULE,
-       .name           = "ext3",
-       .mount          = ext4_mount,
-       .kill_sb        = kill_block_super,
-       .fs_flags       = FS_REQUIRES_DEV,
+       .owner                  = THIS_MODULE,
+       .name                   = "ext3",
+       .init_fs_context        = ext4_init_fs_context,  // in this patch init_fs_context start set ext4_init_fs_context
+       .parameters             = ext4_param_specs,
+       .kill_sb                = kill_block_super,
+       .fs_flags               = FS_REQUIRES_DEV,
 };
===key change part of cebe85d570cf8===


Following logic will decide whether use legacy_init_fs_context base on
exist of init_fs_context, obviously before patch we have no
init_fs_context but after patch we have it

==function alloc_fs_context== 
        .....
        init_fs_context = fc->fs_type->init_fs_context;
        if (!init_fs_context)
                init_fs_context = legacy_init_fs_context;  //before patch cebe85d570cf8, legacy_init_fs_context will be set.
        ret = init_fs_context(fc);

==function alloc_fs_context== 


====code example for set parse function used by fsconfig===
const struct fs_context_operations legacy_fs_context_ops = {
        .free                   = legacy_fs_context_free,
        .dup                    = legacy_fs_context_dup,
        .parse_param            = legacy_parse_param,   
        .parse_monolithic       = legacy_parse_monolithic,
        .get_tree               = legacy_get_tree,
        .reconfigure            = legacy_reconfigure,
};

/*
 * Initialise a legacy context for a filesystem that doesn't support
 * fs_context.
 */
static int legacy_init_fs_context(struct fs_context *fc)
{
        fc->fs_private = kzalloc(sizeof(struct legacy_fs_context), GFP_KERNEL_ACCOUNT);
        if (!fc->fs_private)
                return -ENOMEM;
        fc->ops = &legacy_fs_context_ops;
        return 0;
}
====code for set parse function used by fsconfig===


====final call parse function within fsconfig logic==
vfs_parse_fs_param
145             if (fc->ops->parse_param) {
146                     	ret = fc->ops->parse_param(fc, param); //this will call legacy_parse_param or ext4_parse_param                                   
147                     if (ret != -ENOPARAM)
148                             return ret;
149             }
====final call parse function within fsconfig logic==



Just FYI the fs_type real data show in GDB(init_fs_context= 0 in kernel5.x but in kernel 6.x init_fs_context=ext4_parse_param):

(gdb) p *fs_type
$4 = {name = 0xffffffff822278e1 "ext3", fs_flags = 1, init_fs_context = 0x0 <fixed_percpu_data>, parameters = 0x0 <fixed_percpu_data>,
  mount = 0xffffffff812ec510 <ext4_mount>, kill_sb = 0xffffffff811f7220 <kill_block_super>, owner = 0x0 <fixed_percpu_data>,
  next = 0xffffffff82564600 <ext2_fs_type>, fs_supers = {first = 0x0 <fixed_percpu_data>}, s_lock_key = {<No data fields>},
  s_umount_key = {<No data fields>}, s_vfs_rename_key = {<No data fields>}, s_writers_key = 0xffffffff825645e8, i_lock_key = {<No data fields>},
  i_mutex_key = {<No data fields>}, invalidate_lock_key = {<No data fields>}, i_mutex_dir_key = {<No data fields>}}


> Kind regards,
> Petr

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

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

[Petr Vorel]

> On Mon, Feb 06, 2023 at 05:19:53PM +0100, Petr Vorel wrote:
> > Hi Wei,

> > ...
> > > > Hm, there is a kernel fix from 5.17 [1]. But test fails when I run it on 6.2.0-rc5:

> > > > tst_supported_fs_types.c:165: TINFO: Skipping FUSE based ntfs as requested by the test
> > > > tst_supported_fs_types.c:157: TINFO: Skipping tmpfs as requested by the test
> > > > 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:44: TFAIL: fsconfig(FSCONFIG_SET_STRING) failed: EINVAL (22)

> > > > Isn't it the opposite: we expect to fail, thus TST_EXP_FAIL() should here be
> > > > used?

> > > I have not test on 6.2.0 kernel, i need reproduce this firstly.

> > FYI 6.0.6 is also broken, works on 5.10.46.


> After long investigation i finally get what's happen now since i have
> never touch kernel fs code before :)

> The root caused is cebe85d570cf8 which make udpate initialize of
> ext3_fs_type.
What exactly happen in cebe85d570cf ("ext4: switch to the new mount api")
from v5.17-rc1? This enables fsconfig, thus test *should* be working on >=
v5.17-rc1, right? But it does not.

BTW xfs also uses new mount API 73e5fff98b64 ("xfs: switch to use the new
mount-api") in v5.5-rc1.  Obviously legacy ext2 driver does not use it.

I'd expect fsopen_supported_by_kernel() is enough and no filesystem needs to be
filtered out (at least not real linux filesystems like ext2 or xfs).

> Each file system will initialize a struct file_system_type and ext3 initialize 
> in fs/ext4/super.c(maybe ext3 much same as ext4 so they put in same file).
Yes, ext3 and ext4 share the same code (ext4 driver). This code also servers
ext2 filesystem if CONFIG_EXT4_USE_FOR_EXT2=y (mostly the default), otherwise
there is ext2 driver: CONFIG_EXT2_FS).

Kind regards,
Petr

> This patch add new memeber .init_fs_context in ext3 file_system_type struct and 
> this new member will lead pase function which called by fsconfig change
> from legacy_parse_param to ext4_parse_param(this function will check
> parameter and not allow 0x00)

> ===key change part of cebe85d570cf8===
>  static struct file_system_type ext3_fs_type = {
> -       .owner          = THIS_MODULE,
> -       .name           = "ext3",
> -       .mount          = ext4_mount,
> -       .kill_sb        = kill_block_super,
> -       .fs_flags       = FS_REQUIRES_DEV,
> +       .owner                  = THIS_MODULE,
> +       .name                   = "ext3",
> +       .init_fs_context        = ext4_init_fs_context,  // in this patch init_fs_context start set ext4_init_fs_context
> +       .parameters             = ext4_param_specs,
> +       .kill_sb                = kill_block_super,
> +       .fs_flags               = FS_REQUIRES_DEV,
>  };
> ===key change part of cebe85d570cf8===


> Following logic will decide whether use legacy_init_fs_context base on
> exist of init_fs_context, obviously before patch we have no
> init_fs_context but after patch we have it

> ==function alloc_fs_context== 
>         .....
>         init_fs_context = fc->fs_type->init_fs_context;
>         if (!init_fs_context)
>                 init_fs_context = legacy_init_fs_context;  //before patch cebe85d570cf8, legacy_init_fs_context will be set.
>         ret = init_fs_context(fc);

> ==function alloc_fs_context== 


> ====code example for set parse function used by fsconfig===
> const struct fs_context_operations legacy_fs_context_ops = {
>         .free                   = legacy_fs_context_free,
>         .dup                    = legacy_fs_context_dup,
>         .parse_param            = legacy_parse_param,   
>         .parse_monolithic       = legacy_parse_monolithic,
>         .get_tree               = legacy_get_tree,
>         .reconfigure            = legacy_reconfigure,
> };

> /*
>  * Initialise a legacy context for a filesystem that doesn't support
>  * fs_context.
>  */
> static int legacy_init_fs_context(struct fs_context *fc)
> {
>         fc->fs_private = kzalloc(sizeof(struct legacy_fs_context), GFP_KERNEL_ACCOUNT);
>         if (!fc->fs_private)
>                 return -ENOMEM;
>         fc->ops = &legacy_fs_context_ops;
>         return 0;
> }
> ====code for set parse function used by fsconfig===


> ====final call parse function within fsconfig logic==
> vfs_parse_fs_param
> 145             if (fc->ops->parse_param) {
> 146                     	ret = fc->ops->parse_param(fc, param); //this will call legacy_parse_param or ext4_parse_param                                   
> 147                     if (ret != -ENOPARAM)
> 148                             return ret;
> 149             }
> ====final call parse function within fsconfig logic==



> Just FYI the fs_type real data show in GDB(init_fs_context= 0 in kernel5.x but in kernel 6.x init_fs_context=ext4_parse_param):

> (gdb) p *fs_type
> $4 = {name = 0xffffffff822278e1 "ext3", fs_flags = 1, init_fs_context = 0x0 <fixed_percpu_data>, parameters = 0x0 <fixed_percpu_data>,
>   mount = 0xffffffff812ec510 <ext4_mount>, kill_sb = 0xffffffff811f7220 <kill_block_super>, owner = 0x0 <fixed_percpu_data>,
>   next = 0xffffffff82564600 <ext2_fs_type>, fs_supers = {first = 0x0 <fixed_percpu_data>}, s_lock_key = {<No data fields>},
>   s_umount_key = {<No data fields>}, s_vfs_rename_key = {<No data fields>}, s_writers_key = 0xffffffff825645e8, i_lock_key = {<No data fields>},
>   i_mutex_key = {<No data fields>}, invalidate_lock_key = {<No data fields>}, i_mutex_dir_key = {<No data fields>}}


> > Kind regards,
> > Petr

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

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

[Wei Gao via ltp]

On Wed, Feb 08, 2023 at 04:48:23PM +0100, Petr Vorel wrote:
> > On Mon, Feb 06, 2023 at 05:19:53PM +0100, Petr Vorel wrote:
> > > Hi Wei,
> 
> > > ...
> > > > > Hm, there is a kernel fix from 5.17 [1]. But test fails when I run it on 6.2.0-rc5:
> 
> > > > > tst_supported_fs_types.c:165: TINFO: Skipping FUSE based ntfs as requested by the test
> > > > > tst_supported_fs_types.c:157: TINFO: Skipping tmpfs as requested by the test
> > > > > 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:44: TFAIL: fsconfig(FSCONFIG_SET_STRING) failed: EINVAL (22)
> 
> > > > > Isn't it the opposite: we expect to fail, thus TST_EXP_FAIL() should here be
> > > > > used?
> 
> > > > I have not test on 6.2.0 kernel, i need reproduce this firstly.
> 
> > > FYI 6.0.6 is also broken, works on 5.10.46.
> 
> 
> > After long investigation i finally get what's happen now since i have
> > never touch kernel fs code before :)
> 
> > The root caused is cebe85d570cf8 which make udpate initialize of
> > ext3_fs_type.
> What exactly happen in cebe85d570cf ("ext4: switch to the new mount api")
> from v5.17-rc1? This enables fsconfig, thus test *should* be working on >=
> v5.17-rc1, right? But it does not.
> 

In my test case use "\x00" as fsconfig key parameter, this parameter ONLY
can be accept if kernel using legacy_parse_param. But cebe85d570cf8 make
a change lead kernel start using ext4_parse_param then error will happen
in your test in v5.17, it's normal behaviro.

So the correct behaviro are:
1)you will encounter crash if you running my ltp test case before v5.17. 
2)if you test from v5.17, the security fix 722d94847de29 together with
internal logic change cebe85d570cf8 both happen, and test case will
failed since cebe85d570cf8 change the whole logic and workaround the
security fix 722d94847de29(More detail please see below summary). 

Why 1) not happen now in your test env? 
Since currently my v1 patch has a mistake on loop i number, if you increase loop number i to
5000 then you will encounter crash on kernel before v5.17(ext2/3/4).

+       for (unsigned int i = 0; i < 2; i++) { <====increase this to i < 5000
+               TEST(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
+               if (TST_RET == -1)
+                       tst_brk(TFAIL | TTERRNO, "fsconfig(FSCONFIG_SET_STRING) failed");
+       }



Let me explain more detail for this:

CVE-2022-0185 security bug popped up since 5.1-rc1 and fixed by 722d94847de29 in v5.17-rc1~50, so normally we should check build from v5.17.
Most important thing is this security issue ONLY happen if fsconfig go through legacy_parse_param function(security issue happen and fixed within this function).

But:
For xfs filesystem, from v5.5-rc1 already start use xfs_fs_parse_param instead of  legacy_parse_param, so make no sense check this secruity issue
For ext2&ext3&ext4, after patch cebe85d570cf8 in v5.17-rc1~131^2~36, use ext4_parse_param instead of legacy_parse_param, so also make no sense check 

In summary, we can reject this test case since from v5.17, ext2/ext4/xfs not go through legacy_parse_param and means we can not verify security fix 
722d94847de29(this fix happen in legacy_parse_param.)


Just FYI : fix bug patch which within legacy_parse_param
722d94847de29 (Jamie Hill-Daniel   2022-01-18 08:06:04 +0100 551)       if (size + len + 2 > PAGE_SIZE)
git describe --contains 722d94847de29
v5.17-rc1~50


> BTW xfs also uses new mount API 73e5fff98b64 ("xfs: switch to use the new
> mount-api") in v5.5-rc1.  Obviously legacy ext2 driver does not use it.
> 
> I'd expect fsopen_supported_by_kernel() is enough and no filesystem needs to be
> filtered out (at least not real linux filesystems like ext2 or xfs).
> 
> > Each file system will initialize a struct file_system_type and ext3 initialize 
> > in fs/ext4/super.c(maybe ext3 much same as ext4 so they put in same file).
> Yes, ext3 and ext4 share the same code (ext4 driver). This code also servers
> ext2 filesystem if CONFIG_EXT4_USE_FOR_EXT2=y (mostly the default), otherwise
> there is ext2 driver: CONFIG_EXT2_FS).
> 
> Kind regards,
> Petr
> 
> > This patch add new memeber .init_fs_context in ext3 file_system_type struct and 
> > this new member will lead pase function which called by fsconfig change
> > from legacy_parse_param to ext4_parse_param(this function will check
> > parameter and not allow 0x00)
> 
> > ===key change part of cebe85d570cf8===
> >  static struct file_system_type ext3_fs_type = {
> > -       .owner          = THIS_MODULE,
> > -       .name           = "ext3",
> > -       .mount          = ext4_mount,
> > -       .kill_sb        = kill_block_super,
> > -       .fs_flags       = FS_REQUIRES_DEV,
> > +       .owner                  = THIS_MODULE,
> > +       .name                   = "ext3",
> > +       .init_fs_context        = ext4_init_fs_context,  // in this patch init_fs_context start set ext4_init_fs_context
> > +       .parameters             = ext4_param_specs,
> > +       .kill_sb                = kill_block_super,
> > +       .fs_flags               = FS_REQUIRES_DEV,
> >  };
> > ===key change part of cebe85d570cf8===
> 
> 
> > Following logic will decide whether use legacy_init_fs_context base on
> > exist of init_fs_context, obviously before patch we have no
> > init_fs_context but after patch we have it
> 
> > ==function alloc_fs_context== 
> >         .....
> >         init_fs_context = fc->fs_type->init_fs_context;
> >         if (!init_fs_context)
> >                 init_fs_context = legacy_init_fs_context;  //before patch cebe85d570cf8, legacy_init_fs_context will be set.
> >         ret = init_fs_context(fc);
> 
> > ==function alloc_fs_context== 
> 
> 
> > ====code example for set parse function used by fsconfig===
> > const struct fs_context_operations legacy_fs_context_ops = {
> >         .free                   = legacy_fs_context_free,
> >         .dup                    = legacy_fs_context_dup,
> >         .parse_param            = legacy_parse_param,   
> >         .parse_monolithic       = legacy_parse_monolithic,
> >         .get_tree               = legacy_get_tree,
> >         .reconfigure            = legacy_reconfigure,
> > };
> 
> > /*
> >  * Initialise a legacy context for a filesystem that doesn't support
> >  * fs_context.
> >  */
> > static int legacy_init_fs_context(struct fs_context *fc)
> > {
> >         fc->fs_private = kzalloc(sizeof(struct legacy_fs_context), GFP_KERNEL_ACCOUNT);
> >         if (!fc->fs_private)
> >                 return -ENOMEM;
> >         fc->ops = &legacy_fs_context_ops;
> >         return 0;
> > }
> > ====code for set parse function used by fsconfig===
> 
> 
> > ====final call parse function within fsconfig logic==
> > vfs_parse_fs_param
> > 145             if (fc->ops->parse_param) {
> > 146                     	ret = fc->ops->parse_param(fc, param); //this will call legacy_parse_param or ext4_parse_param                                   
> > 147                     if (ret != -ENOPARAM)
> > 148                             return ret;
> > 149             }
> > ====final call parse function within fsconfig logic==
> 
> 
> 
> > Just FYI the fs_type real data show in GDB(init_fs_context= 0 in kernel5.x but in kernel 6.x init_fs_context=ext4_parse_param):
> 
> > (gdb) p *fs_type
> > $4 = {name = 0xffffffff822278e1 "ext3", fs_flags = 1, init_fs_context = 0x0 <fixed_percpu_data>, parameters = 0x0 <fixed_percpu_data>,
> >   mount = 0xffffffff812ec510 <ext4_mount>, kill_sb = 0xffffffff811f7220 <kill_block_super>, owner = 0x0 <fixed_percpu_data>,
> >   next = 0xffffffff82564600 <ext2_fs_type>, fs_supers = {first = 0x0 <fixed_percpu_data>}, s_lock_key = {<No data fields>},
> >   s_umount_key = {<No data fields>}, s_vfs_rename_key = {<No data fields>}, s_writers_key = 0xffffffff825645e8, i_lock_key = {<No data fields>},
> >   i_mutex_key = {<No data fields>}, invalidate_lock_key = {<No data fields>}, i_mutex_dir_key = {<No data fields>}}
> 
> 
> > > Kind regards,
> > > Petr

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

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

[Cyril Hrubis]

Hi!
> Let me explain more detail for this:
> 
> CVE-2022-0185 security bug popped up since 5.1-rc1 and fixed by 722d94847de29 in v5.17-rc1~50, so normally we should check build from v5.17.
> Most important thing is this security issue ONLY happen if fsconfig go through legacy_parse_param function(security issue happen and fixed within this function).
>
> But:
> For xfs filesystem, from v5.5-rc1 already start use xfs_fs_parse_param instead of  legacy_parse_param, so make no sense check this secruity issue
> For ext2&ext3&ext4, after patch cebe85d570cf8 in v5.17-rc1~131^2~36, use ext4_parse_param instead of legacy_parse_param, so also make no sense check 
> 
> In summary, we can reject this test case since from v5.17, ext2/ext4/xfs not go through legacy_parse_param and means we can not verify security fix 
> 722d94847de29(this fix happen in legacy_parse_param.)

Quite contrary it make sense to add regression tests for kernel and keep them
running on all filesystems and never releases since you never know when
similar mistake will make it into the kernel code again. It does not
make much sense to invest time into tests only to keep them disabled
later on.

More generally it makes sense to try to throw all kind of garbage
strings into fsconfig() and expect to get EINVAL or other sane behavior,
writing such tests is the only way to avoid or at least catch most CVEs
before they happen.

-- 
Cyril Hrubis
chrubis@suse.cz

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

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

[Wei Gao via ltp]

On Thu, Feb 09, 2023 at 11:10:46AM +0100, Cyril Hrubis wrote:
> Hi!
> > Let me explain more detail for this:
> > 
> > CVE-2022-0185 security bug popped up since 5.1-rc1 and fixed by 722d94847de29 in v5.17-rc1~50, so normally we should check build from v5.17.
> > Most important thing is this security issue ONLY happen if fsconfig go through legacy_parse_param function(security issue happen and fixed within this function).
> >
> > But:
> > For xfs filesystem, from v5.5-rc1 already start use xfs_fs_parse_param instead of  legacy_parse_param, so make no sense check this secruity issue
> > For ext2&ext3&ext4, after patch cebe85d570cf8 in v5.17-rc1~131^2~36, use ext4_parse_param instead of legacy_parse_param, so also make no sense check 
> > 
> > In summary, we can reject this test case since from v5.17, ext2/ext4/xfs not go through legacy_parse_param and means we can not verify security fix 
> > 722d94847de29(this fix happen in legacy_parse_param.)
> 
> Quite contrary it make sense to add regression tests for kernel and keep them
> running on all filesystems and never releases since you never know when
> similar mistake will make it into the kernel code again. It does not
> make much sense to invest time into tests only to keep them disabled
> later on.
> 
> More generally it makes sense to try to throw all kind of garbage
> strings into fsconfig() and expect to get EINVAL or other sane behavior,
> writing such tests is the only way to avoid or at least catch most CVEs
> before they happen.
> 

Thanks for review this, i will update the case later.

> -- 
> Cyril Hrubis
> chrubis@suse.cz

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

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

[Wei Gao via ltp]

On Mon, Feb 06, 2023 at 05:38:18AM -0500, Wei Gao via ltp wrote:
> On Wed, Feb 01, 2023 at 01:49:43PM +0100, Petr Vorel wrote:
> > Hi Wei,
> > 
> > ...
> > > +++ b/include/lapi/fsmount.h
> > > @@ -11,12 +11,15 @@
> > >  #include "config.h"
> > >  #include <sys/syscall.h>
> > >  #include <sys/types.h>
> > > -#include <sys/mount.h>
> > 
> > >  #ifndef HAVE_FSOPEN
> > >  # ifdef HAVE_LINUX_MOUNT_H
> > >  #  include <linux/mount.h>
> > > +# else
> > > +#  include <sys/mount.h>
> > >  # endif
> > > +#else
> > > +# include <sys/mount.h>
> > >  #endif
> > Does <linux/mount.h> conflicts with <sys/mount.h>? Or why is this needed?
> > 
> > >  #include "lapi/fcntl.h"
> > > 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
> > 
> > NOTE: you also need to add a new record in testcases/kernel/syscalls/fsconfig/.gitignore.
> > 
> > > diff --git a/testcases/kernel/syscalls/fsconfig/fsconfig03.c b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> > > new file mode 100644
> > > index 000000000..e076c2f09
> > > --- /dev/null
> > > +++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> > > @@ -0,0 +1,58 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * Copyright (c) 2023 Wei Gao <wegao@suse.com>
> > > + */
> > > +
> > > +/*\
> > NOTE, there should be docparse label:
> >  * [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");
> > Sooner or later we should add SAFE_FSOPEN(), but that can wait.
> > 
> > > +
> > > +}
> > > +
> > > +static void cleanup(void)
> > > +{
> > > +	if (fd != -1)
> > > +		SAFE_CLOSE(fd);
> > > +}
> > > +
> > > +static void run(void)
> > > +{
> > > +	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
> > > +
> > > +	for (unsigned int i = 0; i < 2; i++) {
> > > +		TEST(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> > > +		if (TST_RET == -1)
> > > +			tst_brk(TFAIL | TTERRNO, "fsconfig(FSCONFIG_SET_STRING) failed");
> > TST_EXP_PASS() or other could here be used (it should be changes also in fsconfig01.c).
> > 
> > Hm, there is a kernel fix from 5.17 [1]. But test fails when I run it on 6.2.0-rc5:
> > 
> > tst_supported_fs_types.c:165: TINFO: Skipping FUSE based ntfs as requested by the test
> > tst_supported_fs_types.c:157: TINFO: Skipping tmpfs as requested by the test
> > 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:44: TFAIL: fsconfig(FSCONFIG_SET_STRING) failed: EINVAL (22)
> > 
> > Isn't it the opposite: we expect to fail, thus TST_EXP_FAIL() should here be
> > used?
> > 
> I have not test on 6.2.0 kernel, i need reproduce this firstly.
> > > +	}
> > > +	tst_res(TPASS, "Try fsconfig overflow on %s done!", 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,
> > > +	.skip_filesystems = (const char *const []){"fuse", "ext2", "xfs", "tmpfs", NULL},
> > 
> > I wonder why this is should not be run on XFS and ext2.
> ext2: this if failed on one of my specific machine, so normally this should run.
> xfs: this always error happen with error code "TFAIL: fsconfig(FSCONFIG_SET_STRING) failed: EINVAL (22)", i 
> need debug kernel to check what's happen.

Update xfs investigation progress:
After some debug check ths kernel file system code, i found xfs ONLY can accept key which defined in xfs_fs_parameters, so
EINVAL returned.

===xfs kernel logic tracking detail start ===

SYSCALL_DEFINE5(fsconfig   fs/fsopen.c
	vfs_fsconfig_locked
		vfs_parse_fs_param
				ret = fc->ops->parse_param(fc, param);  // this is xfs_fs_parse_param				
					xfs_fs_parse_param
						fs_parse 
							__fs_parse
		
103     int __fs_parse(struct p_log *log,
104                  const struct fs_parameter_spec *desc,
105                  struct fs_parameter *param,
106                  struct fs_parse_result *result)
107     {
108             const struct fs_parameter_spec *p;
109
110             result->uint_64 = 0;
111
(gdb) l
112             p = fs_lookup_key(desc, param, &result->negated);
113             if (!p)
114                     return -ENOPARAM;   <==== this error


static const struct fs_parameter_spec xfs_fs_parameters[] = {
        fsparam_u32("logbufs",          Opt_logbufs),
        fsparam_string("logbsize",      Opt_logbsize),
        fsparam_string("logdev",        Opt_logdev),  <=== ONLY can accept this table as KEY!!
        fsparam_string("rtdev",         Opt_rtdev),
        fsparam_flag("wsync",           Opt_wsync),

===xfs kernel logic tracking detail end===

> > 
> > Also, while we have CVE and kernel fix [1], it should be marked in struct tst_test:
> > 
> > 	.tags = (const struct tst_tag[]) {
> > 		{"linux-git", "722d94847de2"},
> > 		{"CVE", "2020-29373"},
> > 		{"CVE", "2022-0185"},
> > 		{}
> > 	}
> > 
> > Kind regards,
> > Petr
> > 
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=722d94847de2
> > 
> > 
> > > +};
> 
> -- 
> Mailing list info: https://lists.linux.it/listinfo/ltp

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

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

[Wei Gao via ltp]

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

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"},
+		{}
+	}
+};
-- 
2.35.3


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

Re: [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"},
> +		{}
> +	}
> +};

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

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

[Cyril Hrubis]

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.

-- 
Cyril Hrubis
chrubis@suse.cz

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

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

[Petr Vorel]

> 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

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

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

[Cyril Hrubis]

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.

-- 
Cyril Hrubis
chrubis@suse.cz

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

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

[Petr Vorel]

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

Re: [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

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

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

[Petr Vorel]

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

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

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

[Wei Gao via ltp]

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

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

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

[Wei Gao via ltp]

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

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

[LTP] [PATCH v3] fsconfig03: New test CVE-2022-0185

[Wei Gao via ltp]

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

Also with 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/cve                                   |  2 +
 runtest/syscalls                              |  1 +
 testcases/kernel/syscalls/fsconfig/.gitignore |  1 +
 .../kernel/syscalls/fsconfig/fsconfig03.c     | 89 +++++++++++++++++++
 4 files changed, 93 insertions(+)
 create mode 100644 testcases/kernel/syscalls/fsconfig/fsconfig03.c

diff --git a/runtest/cve b/runtest/cve
index 1ba63c2a7..7da3ff853 100644
--- a/runtest/cve
+++ b/runtest/cve
@@ -77,3 +77,5 @@ cve-2022-2590 dirtyc0w_shmem
 # Tests below may cause kernel memory leak
 cve-2020-25704 perf_event_open03
 cve-2022-4378 cve-2022-4378
+# Tests below may cause kernel crash
+cve-2022-0185 fsconfig03
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..8db76484e
--- /dev/null
+++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2022 Alejandro Guerrero <aguerrero@...lys.com>
+ * Copyright (c) 2023 Wei Gao <wegao@suse.com>
+ */
+
+
+/*\
+ * [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";
+	long pagesize;
+
+	pagesize = sysconf(_SC_PAGESIZE);
+	if (pagesize == -1)
+		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
+
+	for (size_t i = 0; i < 5000; i++) {
+		if (!strcmp(tst_device->fs_type, "btrfs")) {
+			/* use same logic in kernel legacy_parse_param function */
+			if (i * (strlen(val) + 2) + (strlen(val) + 1) + 2 > (size_t)pagesize) {
+				TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
+									EINVAL);
+				if (!TST_PASS)
+					return;
+			} else {
+				TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
+				if (TST_ERR)
+					return;
+			}
+		} else {
+			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);
+}
+
+static struct tst_test test = {
+	.test_all = run,
+	.setup = setup,
+	.cleanup = cleanup,
+	.needs_root = 1,
+	.format_device = 1,
+	.mntpoint = MNTPOINT,
+	.all_filesystems = 1,
+	.skip_filesystems = (const char *const []){"ntfs", "vfat", NULL},
+	.tags = (const struct tst_tag[]) {
+		{"linux-git", "722d94847de29"},
+		{"CVE", "2022-0185"},
+		{}
+	}
+};
-- 
2.35.3


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

Re: [LTP] [PATCH v3] fsconfig03: New test CVE-2022-0185

[Richard Palethorpe]

Hello,

Wei Gao via ltp <ltp@lists.linux.it> writes:

> There are reproducers available for CVE-2022-0185
> https://www.openwall.com/lists/oss-security/2022/01/25/14
>
> Also with 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.

This looks like a very good test. IMO we have the most success with
reproducers, but they are hard to write sometimes.

Please state on which kernel(s) you reproduced the bug and whether you
think the test will reliably reproduce the bug.

From my 10 minutes research it looks like a reliable buffer overflow,
but it's always hard to be certain without being very thorough.

>
> Signed-off-by: Wei Gao <wegao@suse.com>
> ---
>  runtest/cve                                   |  2 +
>  runtest/syscalls                              |  1 +
>  testcases/kernel/syscalls/fsconfig/.gitignore |  1 +
>  .../kernel/syscalls/fsconfig/fsconfig03.c     | 89 +++++++++++++++++++
>  4 files changed, 93 insertions(+)
>  create mode 100644 testcases/kernel/syscalls/fsconfig/fsconfig03.c
>
> diff --git a/runtest/cve b/runtest/cve
> index 1ba63c2a7..7da3ff853 100644
> --- a/runtest/cve
> +++ b/runtest/cve
> @@ -77,3 +77,5 @@ cve-2022-2590 dirtyc0w_shmem
>  # Tests below may cause kernel memory leak
>  cve-2020-25704 perf_event_open03
>  cve-2022-4378 cve-2022-4378
> +# Tests below may cause kernel crash
> +cve-2022-0185 fsconfig03
> 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..8db76484e
> --- /dev/null
> +++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> @@ -0,0 +1,89 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2022 Alejandro Guerrero <aguerrero@...lys.com>
> + * Copyright (c) 2023 Wei Gao <wegao@suse.com>
> + */
> +
> +
> +/*\
> + * [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";
> +	long pagesize;
> +
> +	pagesize = sysconf(_SC_PAGESIZE);
> +	if (pagesize == -1)
> +		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
> +
> +	for (size_t i = 0; i < 5000; i++) {
> +		if (!strcmp(tst_device->fs_type, "btrfs")) {
> +			/* use same logic in kernel legacy_parse_param function */
> +			if (i * (strlen(val) + 2) + (strlen(val) + 1) + 2 > (size_t)pagesize) {
> +				TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> +									EINVAL);
> +				if (!TST_PASS)
> +					return;
> +			} else {
> +				TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> +				if (TST_ERR)
> +					return;

We need to close and reopen the FD inside run() otherwise the test fails
on BTRFS with -i2 because we have already filled the buffer.

> +			}
> +		} else {
> +			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> +								EINVAL);
> +			if (!TST_PASS)
> +				return;
> +		}
> +	}

This loop can be rewritten so that there are less branches and
indentation. This makes it easier to read.

	for (size_t i = 0; i < 5000; i++) {
		/* use same logic in kernel legacy_parse_param function */
		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;

		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize) {
			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
			if (TST_ERR)
				return;
		} else {
			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
					    EINVAL);
			if (!TST_PASS)
				return;
		}
	}

Otherwise the test looks good.

> +
> +	tst_res(TPASS, "fsconfig() overflow on %s haven't triggerred crash",
> +			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,
> +	.skip_filesystems = (const char *const []){"ntfs", "vfat", NULL},
> +	.tags = (const struct tst_tag[]) {
> +		{"linux-git", "722d94847de29"},
> +		{"CVE", "2022-0185"},
> +		{}
> +	}
> +};
> -- 
> 2.35.3


-- 
Thank you,
Richard.

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

Re: [LTP] [PATCH v3] fsconfig03: New test CVE-2022-0185

[Wei Gao via ltp]

On Tue, Feb 14, 2023 at 11:05:24AM +0000, Richard Palethorpe wrote:
> Hello,
> 
> > +static void run(void)
> > +{
> > +	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
> > +	long pagesize;
> > +
> > +	pagesize = sysconf(_SC_PAGESIZE);
> > +	if (pagesize == -1)
> > +		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
> > +
> > +	for (size_t i = 0; i < 5000; i++) {
> > +		if (!strcmp(tst_device->fs_type, "btrfs")) {
> > +			/* use same logic in kernel legacy_parse_param function */
> > +			if (i * (strlen(val) + 2) + (strlen(val) + 1) + 2 > (size_t)pagesize) {
> > +				TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> > +									EINVAL);
> > +				if (!TST_PASS)
> > +					return;
> > +			} else {
> > +				TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> > +				if (TST_ERR)
> > +					return;
> 
> We need to close and reopen the FD inside run() otherwise the test fails
> on BTRFS with -i2 because we have already filled the buffer.
Thanks for your feedback, i have some quesiton on this comments:
The error will happen when buffer is full filled on btrfs(means buffer len > pagesize), this is normal 
and current logic verfiy this logic for btrfs.
Are you mean we need create another fd and continue do fsconfig on new fd once first fsconfig fails happen ? Correct 
me if i have misunderstanding.

> 
> > +			}
> > +		} else {
> > +			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> > +								EINVAL);
> > +			if (!TST_PASS)
> > +				return;
> > +		}
> > +	}
> 
> This loop can be rewritten so that there are less branches and
> indentation. This makes it easier to read.
> 
> 	for (size_t i = 0; i < 5000; i++) {
> 		/* use same logic in kernel legacy_parse_param function */
> 		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
> 
> 		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize) {
> 			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> 			if (TST_ERR)
> 				return;
> 		} else {
> 			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> 					    EINVAL);
> 			if (!TST_PASS)
> 				return;
> 		}
> 	}
> 
> 
> > -- 
> > 2.35.3
> 
> 
> -- 
> Thank you,
> Richard.

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

Re: [LTP] [PATCH v3] fsconfig03: New test CVE-2022-0185

[Richard Palethorpe]

Hello,

Wei Gao <wegao@suse.com> writes:

> On Tue, Feb 14, 2023 at 11:05:24AM +0000, Richard Palethorpe wrote:
>> Hello,
>> 
>> > +static void run(void)
>> > +{
>> > +	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
>> > +	long pagesize;
>> > +
>> > +	pagesize = sysconf(_SC_PAGESIZE);
>> > +	if (pagesize == -1)
>> > +		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
>> > +
>> > +	for (size_t i = 0; i < 5000; i++) {
>> > +		if (!strcmp(tst_device->fs_type, "btrfs")) {
>> > +			/* use same logic in kernel legacy_parse_param function */
>> > +			if (i * (strlen(val) + 2) + (strlen(val) + 1) + 2 > (size_t)pagesize) {
>> > +				TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
>> > +									EINVAL);
>> > +				if (!TST_PASS)
>> > +					return;
>> > +			} else {
>> > +				TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
>> > +				if (TST_ERR)
>> > +					return;
>> 
>> We need to close and reopen the FD inside run() otherwise the test fails
>> on BTRFS with -i2 because we have already filled the buffer.
> Thanks for your feedback, i have some quesiton on this comments:
> The error will happen when buffer is full filled on btrfs(means buffer len > pagesize), this is normal 
> and current logic verfiy this logic for btrfs.

I'm not sure you understand what "-i2" means. The run() function can be
called multiple times in a loop. If you do ./fsconfig03 -i2 then you
will see the test fails.

That's because it executes run() twice and the second time
TST_EXP_PASS_SILENT fails.

> Are you mean we need create another fd and continue do fsconfig on new fd once first fsconfig fails happen ? Correct 
> me if i have misunderstanding.

This would also work.

>
>> 
>> > +			}
>> > +		} else {
>> > +			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
>> > +								EINVAL);
>> > +			if (!TST_PASS)
>> > +				return;
>> > +		}
>> > +	}
>> 
>> This loop can be rewritten so that there are less branches and
>> indentation. This makes it easier to read.
>> 
>> 	for (size_t i = 0; i < 5000; i++) {
>> 		/* use same logic in kernel legacy_parse_param function */
>> 		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
>> 
>> 		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize) {
>> 			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
>> 			if (TST_ERR)
>> 				return;
>> 		} else {
>> 			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
>> 					    EINVAL);
>> 			if (!TST_PASS)
>> 				return;
>> 		}
>> 	}
>> 
>> 
>> > -- 
>> > 2.35.3
>> 
>> 
>> -- 
>> Thank you,
>> Richard.


-- 
Thank you,
Richard.

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

Re: [LTP] [PATCH v3] fsconfig03: New test CVE-2022-0185

[Wei Gao via ltp]

On Thu, Feb 16, 2023 at 12:09:20PM +0000, Richard Palethorpe wrote:
> Hello,
> 
> >> We need to close and reopen the FD inside run() otherwise the test fails
> >> on BTRFS with -i2 because we have already filled the buffer.
> > Thanks for your feedback, i have some quesiton on this comments:
> > The error will happen when buffer is full filled on btrfs(means buffer len > pagesize), this is normal 
> > and current logic verfiy this logic for btrfs.
> 
> I'm not sure you understand what "-i2" means. The run() function can be
> called multiple times in a loop. If you do ./fsconfig03 -i2 then you
> will see the test fails.

Yes, i do not understand "-i2" before but i know this now : ) 
I will update and will send new patch soon!

> 
> That's because it executes run() twice and the second time
> TST_EXP_PASS_SILENT fails.
> 
> > Are you mean we need create another fd and continue do fsconfig on new fd once first fsconfig fails happen ? Correct 
> > me if i have misunderstanding.
> 
> This would also work.
> 
> 
> -- 
> Thank you,
> Richard.

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

[LTP] [PATCH v4] fsconfig03: New test CVE-2022-0185

[Wei Gao via ltp]

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

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

When kernel < v5.15.16, you can easily reproduce crash use test case
without check error and return logic in loop.

I have used this test case trigger 5.14.1 kernel crash with ext2/4.
Just make sure your kernel have not patched by following two commits:
e192ccc17ecf3 - fix up param length parsing in legacy_parse_param
cebe85d570cf8 - ext4: switch to the new mount api

Signed-off-by: Wei Gao <wegao@suse.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>
Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
---
 runtest/cve                                   |  2 +
 runtest/syscalls                              |  1 +
 testcases/kernel/syscalls/fsconfig/.gitignore |  1 +
 .../kernel/syscalls/fsconfig/fsconfig03.c     | 79 +++++++++++++++++++
 4 files changed, 83 insertions(+)
 create mode 100644 testcases/kernel/syscalls/fsconfig/fsconfig03.c

diff --git a/runtest/cve b/runtest/cve
index 1ba63c2a7..7da3ff853 100644
--- a/runtest/cve
+++ b/runtest/cve
@@ -77,3 +77,5 @@ cve-2022-2590 dirtyc0w_shmem
 # Tests below may cause kernel memory leak
 cve-2020-25704 perf_event_open03
 cve-2022-4378 cve-2022-4378
+# Tests below may cause kernel crash
+cve-2022-0185 fsconfig03
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..c2e908221
--- /dev/null
+++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2022 Alejandro Guerrero <aguerrero@...lys.com>
+ * Copyright (c) 2023 Wei Gao <wegao@suse.com>
+ */
+
+
+/*\
+ * [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();
+}
+
+static void run(void)
+{
+	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
+	long pagesize;
+
+	TEST(fd = fsopen(tst_device->fs_type, 0));
+	if (fd == -1)
+		tst_brk(TBROK | TTERRNO, "fsopen() failed");
+
+	pagesize = sysconf(_SC_PAGESIZE);
+	if (pagesize == -1)
+		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
+
+	for (size_t i = 0; i < 5000; i++) {
+		/* use same logic in kernel legacy_parse_param function */
+		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
+
+		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize) {
+			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
+			if (TST_ERR)
+				return;
+		} else {
+			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
+					    EINVAL);
+			if (!TST_PASS)
+				return;
+		}
+	}
+
+	if (fd != -1)
+		SAFE_CLOSE(fd);
+
+	tst_res(TPASS, "fsconfig() overflow on %s haven't triggerred crash",
+			tst_device->fs_type);
+}
+
+static struct tst_test test = {
+	.test_all = run,
+	.setup = setup,
+	.needs_root = 1,
+	.format_device = 1,
+	.mntpoint = MNTPOINT,
+	.all_filesystems = 1,
+	.skip_filesystems = (const char *const []){"ntfs", "vfat", NULL},
+	.tags = (const struct tst_tag[]) {
+		{"linux-git", "722d94847de29"},
+		{"CVE", "2022-0185"},
+		{}
+	}
+};
-- 
2.35.3


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

Re: [LTP] [PATCH v4] fsconfig03: New test CVE-2022-0185

[Petr Vorel]

Hi all,

...
> +/*\
> + * [Description]
> + *
> + * Test for CVE-2022-0185.
> + *
> + * References links:
Here needs to be empty blank line (can be fixed before merge).

> + * - https://www.openwall.com/lists/oss-security/2022/01/25/14
> + * - https://github.com/Crusaders-of-Rust/CVE-2022-0185
> + */

Otherwise the final formatting will be without list:
References links: - https://www.openwall.com/lists/oss-security/2022/01/25/14 - https://github.com/Crusaders-of-Rust/CVE-2022-0185

We need some checker which reports that, because nobody knows it.
I also forget on it when putting example for v2.

> +
> +#include "tst_test.h"
> +#include "lapi/fsmount.h"
> +
> +#define MNTPOINT	"mntpoint"
> +
> +static int fd = -1;
> +
> +static void setup(void)
> +{
> +	fsopen_supported_by_kernel();
> +}
> +
> +static void run(void)
> +{
> +	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
> +	long pagesize;
> +
> +	TEST(fd = fsopen(tst_device->fs_type, 0));
> +	if (fd == -1)
> +		tst_brk(TBROK | TTERRNO, "fsopen() failed");

Yes, this is needed to be in test function (it's not enough to be in the
setup()).
> +
> +	pagesize = sysconf(_SC_PAGESIZE);
> +	if (pagesize == -1)
> +		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
> +
> +	for (size_t i = 0; i < 5000; i++) {
> +		/* use same logic in kernel legacy_parse_param function */
> +		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
> +
> +		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize) {
> +			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> +			if (TST_ERR)
> +				return;
> +		} else {
> +			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> +					    EINVAL);
> +			if (!TST_PASS)
> +				return;
> +		}
> +	}
> +
> +	if (fd != -1)
> +		SAFE_CLOSE(fd);
Very good to catch open file descriptor leak (which would leak if this was in
cleanup()).

> +
> +	tst_res(TPASS, "fsconfig() overflow on %s haven't triggerred crash",
> +			tst_device->fs_type);
> +}

It looks to be ready from my site, I'll test it on various kernels to double
check any problem.

Kind regards,
Petr

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

Re: [LTP] [PATCH v4] fsconfig03: New test CVE-2022-0185

[Petr Vorel]

Hi all,

I've tested various kernels, it looks like test works as expected
(older unpatched kernel fails, newer works, very old ones TCONF).

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

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

> When kernel < v5.15.16, you can easily reproduce crash use test case
> without check error and return logic in loop.

> I have used this test case trigger 5.14.1 kernel crash with ext2/4.

> Just make sure your kernel have not patched by following two commits:
> e192ccc17ecf3 - fix up param length parsing in legacy_parse_param
FYI: commit 722d94847de29310e8aa03fcbdb41fc92c521756 upstream.
=> that's a backport of 722d94847de29 we have in .tags in 5.15 stable branch.
This is not obvious, because the hash is different; also hash will be
different for for other kernel stable branches, e.g. in 5.10 stable it's
backported into eadde287a62e66b2f9e62d007c59a8f50d4b8413.

This is misleading, I first wondered if e192ccc17ecf3 shouldn't be in tags
(it shouldn't because it's a backport of 722d94847de29 => we don't put backports
there: "We don’t track all backports to stable kernel but just those which are
stable branch specific (unique), i.e. no commit in mainline. Example of commits:
c4a23c852e80, cac68d12c531." [1]).

Therefore I'd remove this whole section ("Just make sure...").

> cebe85d570cf8 - ext4: switch to the new mount api

I suppose test is now working as expected regardless kernel uses
the old mount API or the new one (from cebe85d570cf8), right?
Is this comment up to date?

Also, nit: kernel commits are usually put in form of hash ("..."), i.e.
e192ccc17ecf ("vfs: fs_context: fix up param length parsing in legacy_parse_param")

Kind regards,
Petr

[1] https://github.com/linux-test-project/ltp/wiki/C-Test-API#138-test-tags

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

Re: [LTP] [PATCH v4] fsconfig03: New test CVE-2022-0185

[Wei Gao via ltp]

On Fri, Feb 17, 2023 at 09:47:04AM +0100, Petr Vorel wrote:
> Hi all,
> 
> I've tested various kernels, it looks like test works as expected
> (older unpatched kernel fails, newer works, very old ones TCONF).
Thanks for great work!
> 
> > There are reproducers available for CVE-2022-0185
> > https://www.openwall.com/lists/oss-security/2022/01/25/14
> 
> > Also with 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.
> 
> > When kernel < v5.15.16, you can easily reproduce crash use test case
> > without check error and return logic in loop.
> 
> > I have used this test case trigger 5.14.1 kernel crash with ext2/4.
> 
> > Just make sure your kernel have not patched by following two commits:
> > e192ccc17ecf3 - fix up param length parsing in legacy_parse_param
> FYI: commit 722d94847de29310e8aa03fcbdb41fc92c521756 upstream.
> => that's a backport of 722d94847de29 we have in .tags in 5.15 stable branch.
> This is not obvious, because the hash is different; also hash will be
> different for for other kernel stable branches, e.g. in 5.10 stable it's
> backported into eadde287a62e66b2f9e62d007c59a8f50d4b8413.
> 
> This is misleading, I first wondered if e192ccc17ecf3 shouldn't be in tags
> (it shouldn't because it's a backport of 722d94847de29 => we don't put backports
> there: "We don’t track all backports to stable kernel but just those which are
> stable branch specific (unique), i.e. no commit in mainline. Example of commits:
> c4a23c852e80, cac68d12c531." [1]).
> 
> Therefore I'd remove this whole section ("Just make sure...").
> 

No problem for me.

> > cebe85d570cf8 - ext4: switch to the new mount api
> 
> I suppose test is now working as expected regardless kernel uses
> the old mount API or the new one (from cebe85d570cf8), right?
> Is this comment up to date?
This commit can impact test result in a very small window, in theory if you test kernel version 
between v5.15.16 ~ v5.17-rc1 for ext2/3/4, fsconfig will not give error until buffer size reach 
a page size. 
 
git describe --contains e192ccc17ecf3   //fix for legacy_parse_param
v5.15.16~24
git describe --contains cebe85d570cf8  //fix for switch new parse function
v5.17-rc1~131^2~36

> 
> Also, nit: kernel commits are usually put in form of hash ("..."), i.e.
> e192ccc17ecf ("vfs: fs_context: fix up param length parsing in legacy_parse_param")
> 
> Kind regards,
> Petr
> 
> [1] https://github.com/linux-test-project/ltp/wiki/C-Test-API#138-test-tags

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

Re: [LTP] [PATCH v4] fsconfig03: New test CVE-2022-0185

[Richard Palethorpe]

Hello,

Wei Gao <wegao@suse.com> writes:

> There are reproducers available for CVE-2022-0185
> https://www.openwall.com/lists/oss-security/2022/01/25/14
>
> Also with 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.
>
> When kernel < v5.15.16, you can easily reproduce crash use test case
> without check error and return logic in loop.
>
> I have used this test case trigger 5.14.1 kernel crash with ext2/4.
> Just make sure your kernel have not patched by following two commits:
> e192ccc17ecf3 - fix up param length parsing in legacy_parse_param
> cebe85d570cf8 - ext4: switch to the new mount api
>
> Signed-off-by: Wei Gao <wegao@suse.com>
> Reviewed-by: Petr Vorel <pvorel@suse.cz>
> Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>
> Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
> ---
>  runtest/cve                                   |  2 +
>  runtest/syscalls                              |  1 +
>  testcases/kernel/syscalls/fsconfig/.gitignore |  1 +
>  .../kernel/syscalls/fsconfig/fsconfig03.c     | 79 +++++++++++++++++++
>  4 files changed, 83 insertions(+)
>  create mode 100644 testcases/kernel/syscalls/fsconfig/fsconfig03.c
>
> diff --git a/runtest/cve b/runtest/cve
> index 1ba63c2a7..7da3ff853 100644
> --- a/runtest/cve
> +++ b/runtest/cve
> @@ -77,3 +77,5 @@ cve-2022-2590 dirtyc0w_shmem
>  # Tests below may cause kernel memory leak
>  cve-2020-25704 perf_event_open03
>  cve-2022-4378 cve-2022-4378
> +# Tests below may cause kernel crash
> +cve-2022-0185 fsconfig03
> 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..c2e908221
> --- /dev/null
> +++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2022 Alejandro Guerrero <aguerrero@...lys.com>
> + * Copyright (c) 2023 Wei Gao <wegao@suse.com>
> + */
> +
> +
> +/*\
> + * [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();
> +}
> +
> +static void run(void)
> +{
> +	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
> +	long pagesize;
> +
> +	TEST(fd = fsopen(tst_device->fs_type, 0));
> +	if (fd == -1)
> +		tst_brk(TBROK | TTERRNO, "fsopen() failed");
> +
> +	pagesize = sysconf(_SC_PAGESIZE);
> +	if (pagesize == -1)
> +		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
> +
> +	for (size_t i = 0; i < 5000; i++) {
> +		/* use same logic in kernel legacy_parse_param function */
> +		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
> +
> +		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize) {
> +			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> +			if (TST_ERR)
> +				return;

Why not keep going if there is an error? Possibly we won't get an Ooops
the first time there is an error, but if we keep going then it will
result in a more serious error. Perhaps in this case it is unlikely, but
I don't see a big downside to keep going.

Generally people pay more attention to stack traces.

> +		} else {
> +			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> +					    EINVAL);
> +			if (!TST_PASS)
> +				return;

Same here.

I know it will result in 1000's of lines of noise, but only in the
failure case.

> +		}
> +	}
> +
> +	if (fd != -1)
> +		SAFE_CLOSE(fd);
> +
> +	tst_res(TPASS, "fsconfig() overflow on %s haven't triggerred crash",
> +			tst_device->fs_type);

It's OK to print pass after printing fail if the pass and fail messages
do not contradict each other.

Actually I now remember that we can check for kernel taints, from the
manual:

1.24 Tainted kernels
~~~~~~~~~~~~~~~~~~~~

If you need to detect whether a testcase triggers a kernel warning, bug or
oops, the following can be used to detect TAINT_W or TAINT_D:

[source,c]
-------------------------------------------------------------------------------
#include "tst_test.h"

static struct tst_test test = {
	...
	.taint_check = TST_TAINT_W | TST_TAINT_D,
	...
};

void run(void)
{
	...
	if (tst_taint_check() != 0)
		tst_res(TFAIL, "kernel has issues");
	else
		tst_res(TPASS, "kernel seems to be fine");
}
-------------------------------------------------------------------------------

...

If fsconfig produces an unexpected result, but there is no Oops this is
usefull for debugging. Especially if it is just the test that is broken.

> +}
> +
> +static struct tst_test test = {
> +	.test_all = run,
> +	.setup = setup,
> +	.needs_root = 1,
> +	.format_device = 1,
> +	.mntpoint = MNTPOINT,
> +	.all_filesystems = 1,
> +	.skip_filesystems = (const char *const []){"ntfs", "vfat", NULL},
> +	.tags = (const struct tst_tag[]) {
> +		{"linux-git", "722d94847de29"},
> +		{"CVE", "2022-0185"},
> +		{}
> +	}
> +};


-- 
Thank you,
Richard.

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

[LTP] [PATCH v5] fsconfig03: New test CVE-2022-0185

[Wei Gao via ltp]

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

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

When kernel < v5.15.16, you can easily reproduce crash use test case
without check error and return logic in loop.

I have used this test case trigger 5.14.1 kernel crash with ext2/4.

Signed-off-by: Wei Gao <wegao@suse.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>
Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
---
 runtest/cve                                   |  2 +
 runtest/syscalls                              |  1 +
 testcases/kernel/syscalls/fsconfig/.gitignore |  1 +
 .../kernel/syscalls/fsconfig/fsconfig03.c     | 79 +++++++++++++++++++
 4 files changed, 83 insertions(+)
 create mode 100644 testcases/kernel/syscalls/fsconfig/fsconfig03.c

diff --git a/runtest/cve b/runtest/cve
index 1ba63c2a7..7da3ff853 100644
--- a/runtest/cve
+++ b/runtest/cve
@@ -77,3 +77,5 @@ cve-2022-2590 dirtyc0w_shmem
 # Tests below may cause kernel memory leak
 cve-2020-25704 perf_event_open03
 cve-2022-4378 cve-2022-4378
+# Tests below may cause kernel crash
+cve-2022-0185 fsconfig03
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..c2e908221
--- /dev/null
+++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2022 Alejandro Guerrero <aguerrero@...lys.com>
+ * Copyright (c) 2023 Wei Gao <wegao@suse.com>
+ */
+
+
+/*\
+ * [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();
+}
+
+static void run(void)
+{
+	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
+	long pagesize;
+
+	TEST(fd = fsopen(tst_device->fs_type, 0));
+	if (fd == -1)
+		tst_brk(TBROK | TTERRNO, "fsopen() failed");
+
+	pagesize = sysconf(_SC_PAGESIZE);
+	if (pagesize == -1)
+		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
+
+	for (size_t i = 0; i < 5000; i++) {
+		/* use same logic in kernel legacy_parse_param function */
+		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
+
+		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize) {
+			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
+			if (TST_ERR)
+				return;
+		} else {
+			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
+					    EINVAL);
+			if (!TST_PASS)
+				return;
+		}
+	}
+
+	if (fd != -1)
+		SAFE_CLOSE(fd);
+
+	tst_res(TPASS, "fsconfig() overflow on %s haven't triggerred crash",
+			tst_device->fs_type);
+}
+
+static struct tst_test test = {
+	.test_all = run,
+	.setup = setup,
+	.needs_root = 1,
+	.format_device = 1,
+	.mntpoint = MNTPOINT,
+	.all_filesystems = 1,
+	.skip_filesystems = (const char *const []){"ntfs", "vfat", NULL},
+	.tags = (const struct tst_tag[]) {
+		{"linux-git", "722d94847de29"},
+		{"CVE", "2022-0185"},
+		{}
+	}
+};
-- 
2.35.3


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

[LTP] [PATCH v6] fsconfig03: New test CVE-2022-0185

[Wei Gao via ltp]

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

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

When kernel < v5.15.16, you can easily reproduce crash use test case
without check error and return logic in loop.

I have used this test case trigger 5.14.1 kernel crash with ext2/4.

Signed-off-by: Wei Gao <wegao@suse.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>
Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
---
 runtest/cve                                   |  2 +
 runtest/syscalls                              |  1 +
 testcases/kernel/syscalls/fsconfig/.gitignore |  1 +
 .../kernel/syscalls/fsconfig/fsconfig03.c     | 79 +++++++++++++++++++
 4 files changed, 83 insertions(+)
 create mode 100644 testcases/kernel/syscalls/fsconfig/fsconfig03.c

diff --git a/runtest/cve b/runtest/cve
index 1ba63c2a7..7da3ff853 100644
--- a/runtest/cve
+++ b/runtest/cve
@@ -77,3 +77,5 @@ cve-2022-2590 dirtyc0w_shmem
 # Tests below may cause kernel memory leak
 cve-2020-25704 perf_event_open03
 cve-2022-4378 cve-2022-4378
+# Tests below may cause kernel crash
+cve-2022-0185 fsconfig03
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..2d9183dd6
--- /dev/null
+++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2022 Alejandro Guerrero <aguerrero@...lys.com>
+ * Copyright (c) 2023 Wei Gao <wegao@suse.com>
+ */
+
+
+/*\
+ * [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();
+}
+
+static void run(void)
+{
+	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
+	long pagesize;
+
+	TEST(fd = fsopen(tst_device->fs_type, 0));
+	if (fd == -1)
+		tst_brk(TBROK | TTERRNO, "fsopen() failed");
+
+	pagesize = sysconf(_SC_PAGESIZE);
+	if (pagesize == -1)
+		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
+
+	for (size_t i = 0; i < 5000; i++) {
+		/* use same logic in kernel legacy_parse_param function */
+		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
+
+		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize)
+			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
+		else
+			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
+					    EINVAL);
+	}
+
+	if (fd != -1)
+		SAFE_CLOSE(fd);
+
+	if (tst_taint_check() != 0)
+		tst_res(TFAIL, "kernel has issues on %s",
+			tst_device->fs_type);
+	else
+		tst_res(TPASS, "kernel seems to be fine on %s",
+			tst_device->fs_type);
+}
+
+static struct tst_test test = {
+	.test_all = run,
+	.setup = setup,
+	.needs_root = 1,
+	.format_device = 1,
+	.mntpoint = MNTPOINT,
+	.all_filesystems = 1,
+	.taint_check = TST_TAINT_W | TST_TAINT_D,
+	.skip_filesystems = (const char *const []){"ntfs", "vfat", NULL},
+	.tags = (const struct tst_tag[]) {
+		{"linux-git", "722d94847de29"},
+		{"CVE", "2022-0185"},
+		{}
+	}
+};
-- 
2.35.3


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

Re: [LTP] [PATCH v6] fsconfig03: New test CVE-2022-0185

[Richard Palethorpe]

Hello,

Merged with minor fixes, thanks!

See comments below.

Wei Gao <wegao@suse.com> writes:

> There are reproducers available for CVE-2022-0185
> https://www.openwall.com/lists/oss-security/2022/01/25/14
>
> Also with 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.
>
> When kernel < v5.15.16, you can easily reproduce crash use test case
> without check error and return logic in loop.
>
> I have used this test case trigger 5.14.1 kernel crash with ext2/4.
>
> Signed-off-by: Wei Gao <wegao@suse.com>
> Reviewed-by: Petr Vorel <pvorel@suse.cz>
> Reviewed-by: Richard Palethorpe <rpalethorpe@suse.com>
> Reviewed-by: Cyril Hrubis <chrubis@suse.cz>
> ---
>  runtest/cve                                   |  2 +
>  runtest/syscalls                              |  1 +
>  testcases/kernel/syscalls/fsconfig/.gitignore |  1 +
>  .../kernel/syscalls/fsconfig/fsconfig03.c     | 79 +++++++++++++++++++
>  4 files changed, 83 insertions(+)
>  create mode 100644 testcases/kernel/syscalls/fsconfig/fsconfig03.c
>
> diff --git a/runtest/cve b/runtest/cve
> index 1ba63c2a7..7da3ff853 100644
> --- a/runtest/cve
> +++ b/runtest/cve
> @@ -77,3 +77,5 @@ cve-2022-2590 dirtyc0w_shmem
>  # Tests below may cause kernel memory leak
>  cve-2020-25704 perf_event_open03
>  cve-2022-4378 cve-2022-4378
> +# Tests below may cause kernel crash

rm this comment, almost all the CVE tests can cause a crash.

I'm not sure why there is a comment about memory leak above. There is no
reason to ever comment about such things in the runtest file.

> +cve-2022-0185 fsconfig03
> 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..2d9183dd6
> --- /dev/null
> +++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> @@ -0,0 +1,79 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2022 Alejandro Guerrero <aguerrero@...lys.com>

Added the full domain which is qualys.com.

> + * Copyright (c) 2023 Wei Gao <wegao@suse.com>
> + */
> +
> +
> +/*\
> + * [Description]
> + *
> + * Test for CVE-2022-0185.
> + *
> + * References links:

Added blank line here as suggested by pvorel

> + * - 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();
> +}
> +
> +static void run(void)
> +{
> +	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
> +	long pagesize;
> +
> +	TEST(fd = fsopen(tst_device->fs_type, 0));
> +	if (fd == -1)
> +		tst_brk(TBROK | TTERRNO, "fsopen() failed");
> +
> +	pagesize = sysconf(_SC_PAGESIZE);
> +	if (pagesize == -1)
> +		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
> +
> +	for (size_t i = 0; i < 5000; i++) {
> +		/* use same logic in kernel legacy_parse_param function */
> +		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
> +
> +		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize)
> +			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> +		else
> +			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> +					    EINVAL);
> +	}
> +
> +	if (fd != -1)
> +		SAFE_CLOSE(fd);
> +
> +	if (tst_taint_check() != 0)

Removed the unecessary '!= 0'

> +		tst_res(TFAIL, "kernel has issues on %s",
> +			tst_device->fs_type);
> +	else
> +		tst_res(TPASS, "kernel seems to be fine on %s",
> +			tst_device->fs_type);
> +}
> +
> +static struct tst_test test = {
> +	.test_all = run,
> +	.setup = setup,
> +	.needs_root = 1,
> +	.format_device = 1,
> +	.mntpoint = MNTPOINT,
> +	.all_filesystems = 1,
> +	.taint_check = TST_TAINT_W | TST_TAINT_D,
> +	.skip_filesystems = (const char *const []){"ntfs", "vfat", NULL},
> +	.tags = (const struct tst_tag[]) {
> +		{"linux-git", "722d94847de29"},
> +		{"CVE", "2022-0185"},
> +		{}
> +	}
> +};


-- 
Thank you,
Richard.

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

Re: [LTP] [PATCH v6] fsconfig03: New test CVE-2022-0185

[Martin Doucha]

Hi,

On 28. 02. 23 4:27, Wei Gao via ltp wrote:
> +	for (size_t i = 0; i < 5000; i++) {
> +		/* use same logic in kernel legacy_parse_param function */
> +		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
> +
> +		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize)
> +			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> +		else
> +			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> +					    EINVAL);
> +	}

This special case for Btrfs is wrong. Btrfs is just the last major 
filesystem which does not implement its own fsconfig() handlers in the 
latest kernel release. But on older kernels, the same applies to other 
filesystems as well.

Any other filesystem that still uses legacy_parse_param() and has the 
CVE fix applied will fail this test with exactly 117 error messages on 
x86. That's how many iterations it takes to fill 4KB buffer with the 
test string.

-- 
Martin Doucha   mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic


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

Re: [LTP] [PATCH v6] fsconfig03: New test CVE-2022-0185

[Wei Gao via ltp]

On Wed, Mar 01, 2023 at 02:46:16PM +0100, Martin Doucha wrote:
> Hi,
> 
> On 28. 02. 23 4:27, Wei Gao via ltp wrote:
> > +	for (size_t i = 0; i < 5000; i++) {
> > +		/* use same logic in kernel legacy_parse_param function */
> > +		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
> > +
> > +		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize)
> > +			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> > +		else
> > +			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> > +					    EINVAL);
> > +	}
> 
> This special case for Btrfs is wrong. Btrfs is just the last major
> filesystem which does not implement its own fsconfig() handlers in the
> latest kernel release. But on older kernels, the same applies to other
> filesystems as well.
> 
For old kernel btrfs ONLY can update legacy_parse_param() so above logic will pass.
> Any other filesystem that still uses legacy_parse_param() and has the CVE
> fix applied will fail this test with exactly 117 error messages on x86.
> That's how many iterations it takes to fill 4KB buffer with the test string.
I expect most of other scenario will use new parse_param function instead of legacy_parse_param.
The security fix should use commit which change parse function instead of update old legacy_parse_param(). 


> 
> -- 
> Martin Doucha   mdoucha@suse.cz
> QA Engineer for Software Maintenance
> SUSE LINUX, s.r.o.
> CORSO IIa
> Krizikova 148/34
> 186 00 Prague 8
> Czech Republic
> 

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

[LTP] [PATCH v7] fsconfig03: SKIP check return value for old kernel

[Wei Gao via ltp]

Signed-off-by: Wei Gao <wegao@suse.com>
---
 .../kernel/syscalls/fsconfig/fsconfig03.c     | 21 ++++++++++++-------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/testcases/kernel/syscalls/fsconfig/fsconfig03.c b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
index 7ee37f4ae..9adf06207 100644
--- a/testcases/kernel/syscalls/fsconfig/fsconfig03.c
+++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
@@ -41,15 +41,20 @@ static void run(void)
 	if (pagesize == -1)
 		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
 
-	for (size_t i = 0; i < 5000; i++) {
-		/* use same logic in kernel legacy_parse_param function */
-		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
+	if ((tst_kvercmp(5, 17, 1)) >= 0) {
+		for (size_t i = 0; i < 5000; i++) {
+			/* use same logic in kernel legacy_parse_param function */
+			const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
 
-		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize)
-			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
-		else
-			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
-					    EINVAL);
+			if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize)
+				TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
+			else
+				TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
+						EINVAL);
+		}
+	} else {
+		for (size_t i = 0; i < 5000; i++)
+			fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0);
 	}
 
 	if (fd != -1)
-- 
2.35.3


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

Re: [LTP] [PATCH v7] fsconfig03: SKIP check return value for old kernel

[Petr Vorel]

Hi Wei,

> Signed-off-by: Wei Gao <wegao@suse.com>
> ---
>  .../kernel/syscalls/fsconfig/fsconfig03.c     | 21 ++++++++++++-------
>  1 file changed, 13 insertions(+), 8 deletions(-)

> diff --git a/testcases/kernel/syscalls/fsconfig/fsconfig03.c b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> index 7ee37f4ae..9adf06207 100644
> --- a/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> +++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> @@ -41,15 +41,20 @@ static void run(void)
>  	if (pagesize == -1)
>  		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");

> -	for (size_t i = 0; i < 5000; i++) {
> -		/* use same logic in kernel legacy_parse_param function */
> -		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
> +	if ((tst_kvercmp(5, 17, 1)) >= 0) {
I suppose 722d94847de29 (in .tags) change the old behavior (from v5.17-rc1).
Shouldn't be the check against 5.17.0?
if ((tst_kvercmp(5, 17, 0)) >= 0) {


> +		for (size_t i = 0; i < 5000; i++) {
> +			/* use same logic in kernel legacy_parse_param function */
> +			const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;

> -		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize)
> -			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> -		else
> -			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> -					    EINVAL);
> +			if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize)
> +				TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> +			else
> +				TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> +						EINVAL);
> +		}
> +	} else {
> +		for (size_t i = 0; i < 5000; i++)
Repeating the loop again. Wouldn't be more readable moving the if clause to
separate function and doing if/else inside of for loop?

Also "\x00" might be in #define (used 3 times).

Kind regards,
Petr

> +			fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0);
>  	}

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

Re: [LTP] [PATCH v7] fsconfig03: SKIP check return value for old kernel

[Wei Gao via ltp]

On Thu, Mar 02, 2023 at 11:00:08AM +0100, Petr Vorel wrote:
> Hi Wei,
> 
> > Signed-off-by: Wei Gao <wegao@suse.com>
> > ---
> >  .../kernel/syscalls/fsconfig/fsconfig03.c     | 21 ++++++++++++-------
> >  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> > diff --git a/testcases/kernel/syscalls/fsconfig/fsconfig03.c b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> > index 7ee37f4ae..9adf06207 100644
> > --- a/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> > +++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
> > @@ -41,15 +41,20 @@ static void run(void)
> >  	if (pagesize == -1)
> >  		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
> 
> > -	for (size_t i = 0; i < 5000; i++) {
> > -		/* use same logic in kernel legacy_parse_param function */
> > -		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
> > +	if ((tst_kvercmp(5, 17, 1)) >= 0) {
> I suppose 722d94847de29 (in .tags) change the old behavior (from v5.17-rc1).
> Shouldn't be the check against 5.17.0?
> if ((tst_kvercmp(5, 17, 0)) >= 0) {
yes, 5.17.0 is better one!
> 
> 
> > +		for (size_t i = 0; i < 5000; i++) {
> > +			/* use same logic in kernel legacy_parse_param function */
> > +			const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
> 
> > -		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize)
> > -			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> > -		else
> > -			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> > -					    EINVAL);
> > +			if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize)
> > +				TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
> > +			else
> > +				TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
> > +						EINVAL);
> > +		}
> > +	} else {
> > +		for (size_t i = 0; i < 5000; i++)
> Repeating the loop again. Wouldn't be more readable moving the if clause to
> separate function and doing if/else inside of for loop?
> 
> Also "\x00" might be in #define (used 3 times).
> 
> Kind regards,
> Petr
> 
> > +			fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0);
> >  	}

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

Re: [LTP] [PATCH v7] fsconfig03: SKIP check return value for old kernel

[Petr Vorel]

Hi Wei,

...
> +	} else {
> +		for (size_t i = 0; i < 5000; i++)
> +			fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0);
Why calling fsconfig() without any check for old kernels? It really looks
strange we don't care about the result. That would deserve an explanation in the
commit message.

Kind regards,
Petr

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

[LTP] [PATCH v8] fsconfig03: SKIP check return value for old kernel

[Wei Gao via ltp]

Signed-off-by: Wei Gao <wegao@suse.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
---
 .../kernel/syscalls/fsconfig/fsconfig03.c     | 37 ++++++++++++-------
 1 file changed, 24 insertions(+), 13 deletions(-)

diff --git a/testcases/kernel/syscalls/fsconfig/fsconfig03.c b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
index 7ee37f4ae..f421b5802 100644
--- a/testcases/kernel/syscalls/fsconfig/fsconfig03.c
+++ b/testcases/kernel/syscalls/fsconfig/fsconfig03.c
@@ -22,36 +22,47 @@
 #define MNTPOINT	"mntpoint"
 
 static int fd = -1;
+static long pagesize;
 
 static void setup(void)
 {
-	fsopen_supported_by_kernel();
-}
+	pagesize = sysconf(_SC_PAGESIZE);
 
-static void run(void)
-{
-	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
-	long pagesize;
+	if (pagesize == -1)
+		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
+
+	fsopen_supported_by_kernel();
 
 	TEST(fd = fsopen(tst_device->fs_type, 0));
 	if (fd == -1)
 		tst_brk(TBROK | TTERRNO, "fsopen() failed");
+}
 
-	pagesize = sysconf(_SC_PAGESIZE);
-	if (pagesize == -1)
-		tst_brk(TBROK, "sysconf(_SC_PAGESIZE) failed");
+static void do_fsconfig(size_t i)
+{
+	char *val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
 
-	for (size_t i = 0; i < 5000; i++) {
-		/* use same logic in kernel legacy_parse_param function */
-		const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
+	/* use same logic in kernel legacy_parse_param function */
+	const size_t len = i * (strlen(val) + 2) + (strlen(val) + 1) + 2;
 
+	if ((tst_kvercmp(5, 17, 0)) >= 0) {
 		if (!strcmp(tst_device->fs_type, "btrfs") && len <= (size_t)pagesize)
 			TST_EXP_PASS_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0));
 		else
 			TST_EXP_FAIL_SILENT(fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0),
-					    EINVAL);
+					EINVAL);
+	} else {
+		fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0);
 	}
 
+}
+
+static void run(void)
+{
+
+	for (size_t i = 0; i < 5000; i++)
+		do_fsconfig(i);
+
 	if (fd != -1)
 		SAFE_CLOSE(fd);
 
-- 
2.35.3


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

Re: [LTP] [PATCH v8] fsconfig03: SKIP check return value for old kernel

[Petr Vorel]

Hi Wei,

thanks a lot for this patch. Because alternative test from Martin was merged
7602a2348 ("fsconfig03: Fix return value validation on older kernels")
I'm closing this in patchwork.

Kind regards,
Petr

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