aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/stackcollapse-report
diff options
context:
space:
mode:
authorLiu Bo <[email protected]>2017-08-09 11:10:16 -0600
committerDavid Sterba <[email protected]>2017-08-21 17:47:14 +0200
commitf716abd55d1e141772fd44a99c07c89f4aff1978 (patch)
tree10a5ae1cd289227f58c2826ee0ba9fde328e27a0 /tools/perf/scripts/python/bin/stackcollapse-report
parentc59efa7eb2400ae356553a8ed5e3f3ef4cc47831 (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 <[email protected]> Signed-off-by: Liu Bo <[email protected]> Signed-off-by: Chris Mason <[email protected]> Signed-off-by: David Sterba <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-report')
0 files changed, 0 insertions, 0 deletions