From: David Sterba <dsterba@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: suy.fnst@cn.fujitsu.com, fdmanana@gmail.com, nborisov@suse.com,
David Sterba <dsterba@suse.com>
Subject: [PATCH v2] btrfs: fix validation of XATTR_ITEM dir items
Date: Thu, 29 Jun 2017 20:20:14 +0200 [thread overview]
Message-ID: <20170629182015.3000-1-dsterba@suse.com> (raw)
The XATTR_ITEM is a type of a directory item so we use the common
validator helper. Unlike other dir items, it can have data. The way the
name len validation is currently implemented does not reflect that. We'd
have to adjust by the data_len when comparing the read and item limits.
However, this will not work for multi-item xattr dir items.
Example from tree dump of generic/337:
item 7 key (257 XATTR_ITEM 751495445) itemoff 15667 itemsize 147
location key (0 UNKNOWN.0 0) type XATTR
transid 8 data_len 3 name_len 11
name: user.foobar
data 123
location key (0 UNKNOWN.0 0) type XATTR
transid 8 data_len 6 name_len 13
name: user.WvG1c1Td
data qwerty
location key (0 UNKNOWN.0 0) type XATTR
transid 8 data_len 5 name_len 19
name: user.J3__T_Km3dVsW_
data hello
At the point of btrfs_is_name_len_valid call we don't have access to the
data_len value of the 2nd and 3rd sub-item. So simple btrfs_dir_data_len(leaf,
di) would always return 3, although we'd need to get 6 and 5 respectively to
get the claculations right. (read_end + name_len + data_len vs item_end)
We'd have to also pass data_len externally, which is not point of the
name validation. The last check is supposed to test if there's at least
one dir item space after the one we're processing. I don't think this is
particularly useful, validation of the next item would catch that too.
So the check is removed and we don't weaken the validation. Now tests
btrfs/048, btrfs/053, generic/273 and generic/337 pass.
Signed-off-by: David Sterba <dsterba@suse.com>
---
fs/btrfs/dir-item.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/fs/btrfs/dir-item.c b/fs/btrfs/dir-item.c
index 2b00dd746118..41cb9196eaa8 100644
--- a/fs/btrfs/dir-item.c
+++ b/fs/btrfs/dir-item.c
@@ -550,14 +550,6 @@ bool btrfs_is_name_len_valid(struct extent_buffer *leaf, int slot,
goto out;
}
- /*
- * This may be the last item in the slot
- * Or same type item(s) is left between read_end and item_end
- */
- if (item_end != read_end && item_end - read_end < size) {
- ret = false;
- goto out;
- }
out:
if (!ret)
btrfs_crit(fs_info, "invalid dir item name len: %u",
--
2.13.0
next reply other threads:[~2017-06-29 18:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 18:20 David Sterba [this message]
2017-06-29 18:20 ` [PATCH] btrfs: fix integer overflow in calc_reclaim_items_nr David Sterba
2017-06-29 18:24 ` David Sterba
2017-07-03 9:05 ` [PATCH v2] btrfs: fix validation of XATTR_ITEM dir items Su Yue
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=20170629182015.3000-1-dsterba@suse.com \
--to=dsterba@suse.com \
--cc=fdmanana@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@suse.com \
--cc=suy.fnst@cn.fujitsu.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).