summaryrefslogtreecommitdiff
path: root/Makefile
diff options
context:
space:
mode:
authorDarrick J. Wong <darrick.wong@oracle.com>2017-02-02 08:56:11 +0100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2017-02-04 09:47:13 +0100
commitb5b4d4a9141e15ea8d887d88d9763cf190955907 (patch)
tree969e195e3ae8268d6e177a10c7a70c2aad0bb0b4 /Makefile
parent5d44dd54bd57c6275d82d8912730c794fc8ec8ab (diff)
xfs: fix bmv_count confusion w/ shared extents
commit c364b6d0b6cda1cd5d9ab689489adda3e82529aa upstream. In a bmapx call, bmv_count is the total size of the array, including the zeroth element that userspace uses to supply the search key. The output array starts at offset 1 so that we can set up the user for the next invocation. Since we now can split an extent into multiple bmap records due to shared/unshared status, we have to be careful that we don't overflow the output array. In the original patch f86f403794b ("xfs: teach get_bmapx about shared extents and the CoW fork") I used cur_ext (the output index) to check for overflows, albeit with an off-by-one error. Since nexleft no longer describes the number of unfilled slots in the output, we can rip all that out and use cur_ext for the overflow check directly. Failure to do this causes heap corruption in bmapx callers such as xfs_io and xfs_scrub. xfs/328 can reproduce this problem. Reviewed-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions