diff options
author | Liu Bo <bo.li.liu@oracle.com> | 2017-08-09 11:10:16 -0600 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2017-08-21 17:47:14 +0200 |
commit | f716abd55d1e141772fd44a99c07c89f4aff1978 (patch) | |
tree | 10a5ae1cd289227f58c2826ee0ba9fde328e27a0 /tools/perf/scripts/python/call-graph-from-sql.py | |
parent | c59efa7eb2400ae356553a8ed5e3f3ef4cc47831 (diff) |
Btrfs: fix out of bounds array access while reading extent buffer
There is a corner case that slips through the checkers in functions
reading extent buffer, ie.
if (start < eb->len) and (start + len > eb->len),
then
a) map_private_extent_buffer() returns immediately because
it's thinking the range spans across two pages,
b) and the checkers in read_extent_buffer(), WARN_ON(start > eb->len)
and WARN_ON(start + len > eb->start + eb->len), both are OK in this
corner case, but it'd actually try to access the eb->pages out of
bounds because of (start + len > eb->len).
The case is found by switching extent inline ref type from shared data
ref to non-shared data ref, which is a kind of metadata corruption.
It'd use the wrong helper to access the eb,
eg. btrfs_extent_data_ref_root(eb, ref) is used but the %ref passing
here is "struct btrfs_shared_data_ref". And if the extent item
happens to be the first item in the eb, then offset/length will get
over eb->len which ends up an invalid memory access.
This is adding proper checks in order to avoid invalid memory access,
ie. 'general protection fault', before it's too late.
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python/call-graph-from-sql.py')
0 files changed, 0 insertions, 0 deletions