Re: Re: Sanity check for m_ialloc_blks in libxfs_mount()

[Dave Chinner <david@fromorbit.com>]

On Thu, Oct 17, 2019 at 08:56:21AM +0200, "Marc Schönefeld" wrote:
> Hi Dave, [resent due to smtp error] 

It got rejected because you sent a HTML-only email to the list.

> thanks for the help, now using the for-next branch, there is still an Arithmetic exception, however somewhere else:

Also, while on list-etiquette, can you please wrap your comments at
72 columns, and please try not to top post as it makes it really hard
to keep the discussion context straight.

> Program received signal SIGFPE, Arithmetic exception.
> xfs_ialloc_setup_geometry (mp=mp@entry=0x6a5e60 <xmount>) at xfs_ialloc.c:2792
> 2792 do_div(icount, igeo->ialloc_blks);

So, same as last time, there's a discrepancy between two fields
in the superblock: sbp->sb_inopblock and sbp->sb_inopblog.

Basically, the inodes per block is smaller than the log2 value of
the number of inodes per block. which implies that sb_inopblog is
greater than 7, unless you've configured the filesystem with a block
size > 4kB.

It also implies that this verifier check:

	(sbp->sb_blocklog - sbp->sb_inodelog != sbp->sb_inopblog)

has also passed, which means either sb_blocklog (the filesystem
block size) and/or the sb_inodelog (inode size) values have also
been tweaked in a way for this test to pass, but to still ahve an
a mismatch betwen sb_inopblock and sb_inopblog.

But we also have a check:

	sbp->sb_inopblock != howmany(sbp->sb_blocksize,sbp->sb_inodesize)

which checks taht the number of inodes per block matches the
filesystem block size and the inode size configured, and:

	sbp->sb_blocksize != (1 << sbp->sb_blocklog)

and
	sbp->sb_inodesize != (1 << sbp->sb_inodelog)

which validate the log2 values match the byte based values.

So I can't see how it got to this code with such a mismatch unless
xfs_db actually ignored it.  And without all the output from xfs_db,
I don't know what errors it has detected and ignored. Hence, when
reporting a problem, can you please include the full output from the
program that has failed, including the command line used to invoke
it?

Further, knowing what the filesystem geometry is supposed to be
tells me an awful lot, too, which is why I asked this last time:

> I'm guessing that you are fuzzing filesystem images and the issue is
> that the inode geometry values in the superblock have been fuzzed to
> be incorrect? What fuzzer are you using to generate the image, and
> what's the mkfs.xfs output that was used to create the base image
> that was then fuzzed?

Because then I know what the values are supposed to be before I look
at the fuzzed image and can clearly tell waht has been manipulated
by the fuzzer.

Also, keep in mind that xfs_db is a diagnostic tool for developers -
it's not a user tool. We use it for digging around in corrupt
structures and hence it often reports then ignores corruption iti
detects so it can display the corrupt structure to the user. i.e.
it's a tool intended to what it is asked to do regardless of the
fact it might not be able to handle the result cleanly.

Hence I'm not sure there is a huge value in actually fuzz testing
xfs_db. It's certainly not at all interesting from a security point
of view...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com