public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "\"Marc Schönefeld\"" <marc.schoenefeld@gmx.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: Sanity check for m_ialloc_blks in libxfs_mount()
Date: Thu, 17 Oct 2019 07:28:59 +1100	[thread overview]
Message-ID: <20191016202859.GI16973@dread.disaster.area> (raw)
In-Reply-To: <trinity-92785614-c99b-4de9-98e8-71be71c0df0d-1571252931141@3c-app-gmx-bs59>

On Wed, Oct 16, 2019 at 09:08:51PM +0200, "Marc Schönefeld" wrote:
> Hi all, 
> 
> it looks like there is a sanity check missing for the divisor
> (m_ialloc_blks) in line 664 of xfsprogs-5.2.1/libxfs/init.c: 
> Program received signal SIGFPE, Arithmetic exception.
> 
> 0x0000000000427ddf in libxfs_mount (mp=mp@entry=0x6a2de0 <xmount>, sb=sb@entry=0x6a2de0 <xmount>, dev=18446744073709551615, 
>     logdev=<optimized out>, rtdev=<optimized out>, flags=flags@entry=1) at init.c:663
> 
> which is 
> 
>     663                 mp->m_maxicount = XFS_FSB_TO_INO(mp,
>     664                                 (mp->m_maxicount / mp->m_ialloc_blks) *
>     665                                  mp->m_ialloc_blks);

That's code is gone now. The current calculation in the dev tree is
quite different thanks to:

commit 3a05ab227ebd5982f910f752692c87005c7b3ad3
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Wed Aug 28 12:08:08 2019 -0400

    xfs: refactor inode geometry setup routines
    
    Source kernel commit: 494dba7b276e12bc3f6ff2b9b584b6e9f693af45
    
    Migrate all of the inode geometry setup code from xfs_mount.c into a
    single libxfs function that we can share with xfsprogs.
    
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Dave Chinner <dchinner@redhat.com>
    Signed-off-by: Eric Sandeen <sandeen@sandeen.net>

And so it doesn't have a divide-by-zero vector in it anymore. 

So it's probably best that you update your source tree to the latest
for-next and retest. It's almost always a good idea to test against
the latest dev tree, that way you aren't finding bugs we've already
found and fixed...

> In case it would be required I have a reproducer file for this,
> which I can share via pm. The bug is reachable from user input via
> the "xfs_db -c _cmd_ _xfsfile_" command.   

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?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2019-10-16 20:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16 19:08 Sanity check for m_ialloc_blks in libxfs_mount() "Marc Schönefeld"
2019-10-16 20:28 ` Dave Chinner [this message]

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20191016202859.GI16973@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=marc.schoenefeld@gmx.org \
    /path/to/YOUR_REPLY

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

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