https://github.com/torvalds/linux
Revision c364b6d0b6cda1cd5d9ab689489adda3e82529aa authored by Darrick J. Wong on 26 January 2017, 17:50:30 UTC, committed by Darrick J. Wong on 26 January 2017, 17:50:30 UTC
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>
1 parent 2aa6ba7
History
Tip revision: c364b6d0b6cda1cd5d9ab689489adda3e82529aa authored by Darrick J. Wong on 26 January 2017, 17:50:30 UTC
xfs: fix bmv_count confusion w/ shared extents
Tip revision: c364b6d
File Mode Size
Documentation
arch
block
certs
crypto
drivers
firmware
fs
include
init
ipc
kernel
lib
mm
net
samples
scripts
security
sound
tools
usr
virt
.cocciconfig -rw-r--r-- 59 bytes
.get_maintainer.ignore -rw-r--r-- 31 bytes
.gitattributes -rw-r--r-- 30 bytes
.gitignore -rw-r--r-- 1.3 KB
.mailmap -rw-r--r-- 7.7 KB
COPYING -rw-r--r-- 18.3 KB
CREDITS -rw-r--r-- 96.0 KB
Kbuild -rw-r--r-- 2.8 KB
Kconfig -rw-r--r-- 252 bytes
MAINTAINERS -rw-r--r-- 382.5 KB
Makefile -rw-r--r-- 57.6 KB
README -rw-r--r-- 722 bytes

README

back to top