On Thu, May 25, 2017 at 10:09:06AM +0800, Su Yue wrote:
> When reading out name from inode_ref, dir_item, it's possible that
> corrupted name_len lead to read beyond boundary.
>
> Since there are already patches for btrfs-progs, this is for btrfs.
>
> Introduce function btrfs_check_namelen, it should be called before reading
> name from extent_buffer.
> The function compares arg @namelen with boundary then returns 'proper'
> namelen.
>
> Signed-off-by: Su Yue <suy.fnst@xxxxxxxxxxxxxx>
Such validation is useful, but I'm concerned about the proposed
implementation and usage pattern.
> +/*
> + * Returns >0: the value @namelen after cut according item boundary
> + * Returns 0: on error
> + */
> +u16 btrfs_check_namelen(struct extent_buffer *leaf, int slot,
> + unsigned long start, u32 namelen)
This function does not match its name, it does not check, but somehow
sanitizes the input length read from the leaf. From a "check" I'd expect
some good/bad result, so it could be used in an if statement.
> +{
> + u32 end;
> + u64 ret = namelen;
> +
> + end = btrfs_leaf_data(leaf) + btrfs_item_end_nr(leaf, slot);
> +
> + if (start > end)
> + return 0;
> + if (start + namelen > end) {
> + ret = end - start;
> + if (ret > U16_MAX)
Where does this limit come from?
> + ret = 0;
> + }
> + return ret;
ret is u64, function returns u16.
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
