linux-ext4 - Re: [Bug report]: fstests g/388 crash on ext4, BUG: kernel NULL pointer dereference, address: 0000000000000000

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ejaxnieh5h6bfeocb7gwtonirthjvpgoveqvmfnb5ebqk33uxs@4lvgdocvt55c>
Date: Mon, 15 Jul 2024 08:01:54 +0000
From: Daniel Gomez <da.gomez@...sung.com>
To: Theodore Ts'o <tytso@....edu>
CC: Zorro Lang <zlang@...hat.com>, "linux-ext4@...r.kernel.org"
	<linux-ext4@...r.kernel.org>, "fstests@...r.kernel.org"
	<fstests@...r.kernel.org>, "Darrick J. Wong" <djwong@...nel.org>
Subject: Re: [Bug report]: fstests g/388 crash on ext4, BUG: kernel NULL
 pointer dereference, address: 0000000000000000

On Mon, Jul 15, 2024 at 12:28:03AM GMT, Theodore Ts'o wrote:
> On Sun, Jul 14, 2024 at 11:46:24AM +0800, Zorro Lang wrote:
> > 
> > A weird kernel panic on ext4 happened when I tried to test a
> > fstests patchset:
> > https://lore.kernel.org/fstests/20240712093341.ftesijixy2yrjlxx@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com/T/#med4b8d2fe14ef627519d84474b4cd1a25d386f75
> 
> I'm confused; this patch set:
> 
> Daniel Gomez (5):
>       common/config: fix RECREATE_TEST_DEV initialization
>       common/rc: add recreation support for tmpfs
>       common/config: enable section parsing when recreation
>       common/rc: read config section mount options for scratch devs
>       common/rc: print test mount options
> 
> seems to be mostly about how xfstest config section handling
> especially for tmpfs.  Is this realy the right patch set?  If so, I'm

Just to clarify, the changes in the patch set above will not only affect tmpfs
(I renamed the header in v2 because of that). Mainly because the common mount
options for both scratch and test devices were not properly handled in the cases
described.

> guessing that the reproducer would be very specific to the xfstests
> config.

I agree with this. Can you share Zorro your config?

My guess is that '-o acl,user_xattr' [1] options are now included in the scratch
device and they were not before. This is what patch 4 fixes. f2fs, tmpfs,
reiserfs, gfs2 and ext* will be affected as well with their respective default
mount options.

Also, the test device will now include the default mount options if
RECREATE_TEST_DEV is enabled.

[1] From _common_mount_opts(). Snippet:

	ext2|ext3|ext4|ext4dev)
		# acls & xattrs aren't turned on by default on ext$FOO
		echo "-o acl,user_xattr $EXT_MOUNT_OPTIONS"
		;;

> 
> My {kvm,gce}-xfstest setup doesn't use the config sections at
> all, but instead uses shell script fragments, since it predates config
> sections by three years --- and I need something that works well with
> sharding separate configs to run on separate cloud VM's.

Similar to the fragments, my workaround for tmpfs has been to export
TMPFS_MOUNT_OPTIONS so it had the default mount options + the config section
mount option I was testing.

> 
> So I'm not sure I'm going to be able to reprduce this easily using my
> test setup.  Can you translate the stack trace to source file names /

Can you confirm if you are including '-o acl,user_xattr' in all your fragments?

> line numbers?  Maybe that will give me a hint what's going on:
> 
> > [35346.372867] Call Trace:
> > [35346.375319]  <TASK>
> > [35346.377426]  ? __die+0x20/0x70
> > [35346.380493]  ? page_fault_oops+0x116/0x230
> > [35346.384602]  ? __pfx_page_fault_oops+0x10/0x10
> > [35346.389048]  ? _raw_spin_unlock+0x29/0x50
> > [35346.393072]  ? rcu_is_watching+0x11/0xb0
> > [35346.397006]  ? exc_page_fault+0x59/0xe0
> > [35346.400854]  ? asm_exc_page_fault+0x22/0x30
> > [35346.405049]  ? folio_mark_dirty+0x2a/0xf0
> > [35346.409072]  __ext4_block_zero_page_range+0x50c/0x7b0 [ext4]
> > [35346.414809]  ext4_truncate+0xcd3/0x1210 [ext4]
> 
> Getting line numbers for these two functions would be especially
> helpful.
> 
> Thanks,
> 
> 					- Ted