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 17:02:39 +1000 [thread overview]
Message-ID: <20180604070239.GP10363@dastard> (raw)
In-Reply-To: <20180604042227.GO10363@dastard>
On Mon, Jun 04, 2018 at 02:22:27PM +1000, Dave Chinner wrote:
> On Sun, Jun 03, 2018 at 10:07:52PM -0400, Wen Xu wrote:
> 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.
Running a debug kernel assert fails in extent allocation setup for
writeback, tripping over a bad extent alignment. The superblock
has an invalid stripe alignment/width setup, which I've fixed.
The extent size hint on the inode also has an invalid alignment (not
a multiple of block size), which the inode verifiers will now catch,
such as this:
XFS (loop0): Metadata corruption detected at xfs_inode_validate_extsize+0xe5/0x110, inode 0x6d5 dinode
XFS (loop0): Unmount and run xfs_repair
XFS (loop0): First 128 bytes of corrupted metadata buffer:
....
And the alignment assert has now gone away. Now there's an assert
like this:
XFS: Assertion failed: *len > 0, file: fs/xfs/xfs_extent_busy.c, line: 344
Call Trace:
xfs_extent_busy_trim+0x243/0x250
xfs_alloc_ag_vextent_exact+0xc3/0x3b0
xfs_alloc_ag_vextent+0x1c9/0x330
xfs_alloc_vextent+0x56a/0x870
xfs_ialloc_ag_alloc+0x160/0x6f0
xfs_dialloc+0x116/0x270
xfs_ialloc+0x5c/0x5e0
xfs_dir_ialloc+0x6a/0x260
xfs_create+0x418/0x670
xfs_generic_create+0x1f6/0x2c0
vfs_create+0xf9/0x180
do_mknodat+0x1f9/0x210
do_syscall_64+0x5a/0x180
entry_SYSCALL_64_after_hwframe+0x49/0xbe
I'm pretty sure this is because there are bogus extent records in
the free space tree - pretty sure we can catch them on lookup
via a change to ->init_key_from_rec() to validate the record before
letting them be used.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-06-04 7:02 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
2018-06-04 4:52 ` Wen Xu
2018-06-04 7:02 ` Dave Chinner [this message]
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=20180604070239.GP10363@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.