aboutsummaryrefslogtreecommitdiffstats
path: root/MAINTAINERS
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@redhat.com>2018-12-21 08:42:50 -0800
committerDarrick J. Wong <darrick.wong@oracle.com>2018-12-21 08:42:50 -0800
commit3cc31fa65d85610574c0f6a474e89f4c419923d5 (patch)
tree879ff2132f5bb4fff6bcf39af0a77881e6ac1e4e /MAINTAINERS
parentLinux 4.20-rc7 (diff)
downloadlinux-dev-3cc31fa65d85610574c0f6a474e89f4c419923d5.tar.xz
linux-dev-3cc31fa65d85610574c0f6a474e89f4c419923d5.zip
iomap: don't search past page end in iomap_is_partially_uptodate
iomap_is_partially_uptodate() is intended to check wither blocks within the selected range of a not-uptodate page are uptodate; if the range we care about is up to date, it's an optimization. However, the iomap implementation continues to check all blocks up to from+count, which is beyond the page, and can even be well beyond the iop->uptodate bitmap. I think the worst that will happen is that we may eventually find a zero bit and return "not partially uptodate" when it would have otherwise returned true, and skip the optimization. Still, it's clearly an invalid memory access that must be fixed. So: fix this by limiting the search to within the page as is done in the non-iomap variant, block_is_partially_uptodate(). Zorro noticed thiswhen KASAN went off for 512 byte blocks on a 64k page system: BUG: KASAN: slab-out-of-bounds in iomap_is_partially_uptodate+0x1a0/0x1e0 Read of size 8 at addr ffff800120c3a318 by task fsstress/22337 Reported-by: Zorro Lang <zlang@redhat.com> Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Eric Sandeen <sandeen@sandeen.net> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions