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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).