From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs: abort extended attribute list operation if btree is obviously weird
Date: Tue, 24 Oct 2017 08:53:36 -0400 [thread overview]
Message-ID: <20171024125336.GB56184@bfoster.bfoster> (raw)
In-Reply-To: <20171024002824.GL5483@magnolia>
On Mon, Oct 23, 2017 at 05:28:24PM -0700, Darrick J. Wong wrote:
> Abort an attribute list operation if the attr btree has obvious problems
> like loops back to the root or pointers don't point down the tree.
> Found by fuzzing btree[0].before to zero in xfs/402.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> fs/xfs/xfs_attr_list.c | 54 ++++++++++++++++++++++++++++++++++++++----------
> 1 file changed, 43 insertions(+), 11 deletions(-)
>
> diff --git a/fs/xfs/xfs_attr_list.c b/fs/xfs/xfs_attr_list.c
> index 5816786..9f6fcc6 100644
> --- a/fs/xfs/xfs_attr_list.c
> +++ b/fs/xfs/xfs_attr_list.c
...
> @@ -302,6 +306,30 @@ xfs_attr_node_list(xfs_attr_list_context_t *context)
> }
>
> dp->d_ops->node_hdr_from_disk(&nodehdr, node);
> +
> + /* Tree taller than we can handle; bail out! */
> + if (nodehdr.level >= XFS_DA_NODE_MAXDEPTH) {
> + xfs_trans_brelse(context->tp, bp);
> + return -EFSCORRUPTED;
> + }
> +
> + if (cursor->blkno == 0) {
> + /*
> + * This is the root node, set up for the
> + * next level we want to see.
> + */
> + expected_level = nodehdr.level - 1;
> + } else if (expected_level != nodehdr.level) {
> + /*
> + * Not the level we were expecting, which
> + * implies that the tree is bad.
> + */
> + xfs_trans_brelse(context->tp, bp);
> + return -EFSCORRUPTED;
> + } else {
> + expected_level--;
> + }
> +
It looks like we wouldn't catch the case of a two level tree having a
bad level, since we'd break out on leaf magic check above. Perhaps we
should check or assert that expected_level reaches 0? Otherwise looks Ok
to me.
Brian
> btree = dp->d_ops->node_tree_p(node);
> for (i = 0; i < nodehdr.count; btree++, i++) {
> if (cursor->hashval
> @@ -317,6 +345,10 @@ xfs_attr_node_list(xfs_attr_list_context_t *context)
> return 0;
> }
> xfs_trans_brelse(context->tp, bp);
> +
> + /* We can't point back to the root. */
> + if (cursor->blkno == 0)
> + return -EFSCORRUPTED;
> }
> }
> ASSERT(bp != NULL);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-10-24 12:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-24 0:28 [PATCH] xfs: abort extended attribute list operation if btree is obviously weird Darrick J. Wong
2017-10-24 12:53 ` Brian Foster [this message]
2017-10-24 17:00 ` 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=20171024125336.GB56184@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.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 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.