[Top] [All Lists]

Re: xfs_repair segfault

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: xfs_repair segfault
From: Viet Nguyen <vietnguyen@xxxxxxxxx>
Date: Mon, 7 Oct 2013 13:09:09 -0700
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8X+wHSSqgVvrILEIE1nHp4YjnsodPmf+H1WwChidaQU=; b=qGLtfRmTFMGv5flYdyCB86dToQuTd38JxKC/oe69R9X8+yFXIXQbkq+bTi3wlvVrFq LYRdP3o4SNl0gwid8mwsT9iM22jHTEJpVBRiQRigp214VGgscKVm9iMpqTIhtz5o7CH2 Emi1kjHGizegBufQNXp5wMBoZzX2BIP2Ok/gemvws5hQeiTvl8zDHLYGctOdv/ZGukEi SQs8rOpYWOrnAdTz1Am7oQXimiuuzurmY7f3MM5dnx7sDle8iShWOx9J3qTBZqJbhU3P brnWBMgVZcEHhEzwDmxSG+yYIRI2N6piNx0OvZkF2T6eutRHCSsxtBb/1kMRs1jj1qoN MyCg==
In-reply-to: <20131004214353.GK4446@dastard>
References: <CAGa4098ZKd2KQfWMgNXYgLr9LJF8r-MpFgQAn3G-W+ovDGHTAw@xxxxxxxxxxxxxx> <20131001201909.GR12541@dastard> <CAGa409_tDjbsdnf+wDiM7666FeQSjmMfOVdqG-SxOD_WUZMiZQ@xxxxxxxxxxxxxx> <20131002104253.GT12541@dastard> <CAGa409_wO74zGP1d85RGZ7WbfBPr7s_tKaW3u9k8=9Ps-D5FjQ@xxxxxxxxxxxxxx> <20131004214353.GK4446@dastard>
Thanks. That seemed to fix that bug.

Now I'm getting a lot of this:
xfs_da_do_buf(2): XFS_CORRUPTION_ERROR

fatal error -- can't read block 8388608 for directory inode 8628218

Then xfs_repair exits.

What I've been doing is what I saw in the FAQ where I would use xfs_db and write core.mode 0 for these inodes. But there are just so many of them. And is that even the right thing to do?


On Fri, Oct 4, 2013 at 2:43 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
On Fri, Oct 04, 2013 at 10:51:50AM -0700, Viet Nguyen wrote:
> Hi,
> I was wondering if you got a chance to look at this and if one's available,
> where can I get a patch?

Can you try the patch below?


Dave Chinner

libxfs: validity check the directory block leaf entry count

From: Dave Chinner <dchinner@xxxxxxxxxx>

The directory block format verifier fails to check that the leaf
entry count is in a valid range, and so if it is corrupted then it
can lead to derefencing a pointer outside the block buffer. While we
can't exactly validate the count without first walking the directory
block, we can ensure the count lands in the valid area within the
directory block and hence avoid out-of-block references.

Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
 libxfs/xfs_dir2_data.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/libxfs/xfs_dir2_data.c b/libxfs/xfs_dir2_data.c
index 189699f..1b5196b 100644
--- a/libxfs/xfs_dir2_data.c
+++ b/libxfs/xfs_dir2_data.c
@@ -59,6 +59,18 @@ __xfs_dir3_data_check(
                btp = xfs_dir2_block_tail_p(mp, hdr);
                lep = xfs_dir2_block_leaf_p(btp);
                endp = (char *)lep;
+               /*
+                * The number of leaf entries is limited by the size of the
+                * block and the amount of space used by the data entries.
+                * We don't know how much space is used by the data entries yet,
+                * so just ensure that the count falls somewhere inside the
+                * block right now.
+                */
+               XFS_WANT_CORRUPTED_RETURN(be32_to_cpu(btp->count) >
+                               ((char *)btp - (char *)p) /
+                                       sizeof(struct xfs_dir2_leaf_entry));
        case cpu_to_be32(XFS_DIR3_DATA_MAGIC):
        case cpu_to_be32(XFS_DIR2_DATA_MAGIC):

<Prev in Thread] Current Thread [Next in Thread>