From: Dave Chinner <david@fromorbit.com>
To: Wen Xu <xuwen.sjtu@gmail.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: NULL pointer dereference in xfs_bmap_extents_to_btree() when mounting and operating a crafted image
Date: Mon, 4 Jun 2018 14:22:27 +1000 [thread overview]
Message-ID: <20180604042227.GO10363@dastard> (raw)
In-Reply-To: <CANrHXgwP5nOaG6nZwUs-bM_oJDNdUnXj=33xrrLJ-OvyCaz_EA@mail.gmail.com>
On Sun, Jun 03, 2018 at 10:07:52PM -0400, Wen Xu wrote:
> Hi Dave,
>
> Very strange.
>
> I checkout v4.17-rc7 of
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
> and merge with for-next of
> https://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git/ to make the
> kernel build.
The last commit from the for-next tree I have is:
d25522f10cfa xfs: repair superblocks
Does that match what you merged?
> d1dabff17081af94c9604c5fdddd0de7 20.img
> mounting 20.img and running poc.c on mounted folder still gives me
> nullptr access.
>
> [ 1381.524410] XFS (loop0): Mounting V4 Filesystem
> [ 1381.524484] XFS (loop0): Log size 864 blocks too small, minimum
> size is 942 blocks
> [ 1381.524487] XFS (loop0): Log size out of supported range.
> [ 1381.525728] XFS (loop0): Continuing onwards, but if log hangs are
> experienced then please report this message in the bug report.
> [ 1381.533754] XFS (loop0): Ending clean mount
> [ 1388.369552] XFS (loop0): xfs_buf_find: daddr 0x7fb28 out of range, EOFS 0x8000
So, somehow, it's getting a block beyond EOF being allocated out of
the free space tree. So what we have here is an uncaught corrupt
freespace record....
<sigh>
$ sudo xfs_repair -n -f xfs.img
Phase 1 - find and verify superblock...
bad primary superblock - inconsistent filesystem geometry in
realtime filesystem component !!!
attempting to find secondary superblock...
...Sorry, could not find valid secondary superblock
Exiting now.
$
Please use a filesystem with at least 2 AGs as the basis of your
fuzzing in future.
But, yeah, xfs_db tells me the by-size freespace btree is full of
crap, but the by-cnt tree is completely empty (i.e. corrupt) so
allocation should definitely be failing long before if gets anywhere
near returning an allocated block.
Ok, I just worked out why I haven't been able to reproduce the
issue: you have no error checking in your test code, so I get no
indication that it fails to run correctly when run as a user.
Alright, lets start this whole thing again.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-06-04 4:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-03 22:19 NULL pointer dereference in xfs_bmap_extents_to_btree() when mounting and operating a crafted image Wen Xu
2018-06-03 22:34 ` Dave Chinner
2018-06-03 22:59 ` Darrick J. Wong
2018-06-03 23:03 ` Dave Chinner
2018-06-03 23:08 ` Darrick J. Wong
2018-06-03 23:31 ` Dave Chinner
2018-06-04 2:07 ` Wen Xu
2018-06-04 4:22 ` Dave Chinner [this message]
2018-06-04 4:52 ` Wen Xu
2018-06-04 7:02 ` Dave Chinner
2018-06-29 17:02 ` Wen Xu
2018-06-30 18:32 ` Darrick J. Wong
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=20180604042227.GO10363@dastard \
--to=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=xuwen.sjtu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.