summaryrefslogtreecommitdiff
path: root/fs/ocfs2
diff options
context:
space:
mode:
authorEric Sandeen <sandeen@redhat.com>2018-12-21 19:42:50 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-01-26 11:32:43 +0300
commitc9dcb871b1a99301ba65685be95cbd93a5c540fe (patch)
tree161b3884cffc79c31413f082132b06e16a445d85 /fs/ocfs2
parent00886cebcce534ad228d9530fc8df56af666ccc5 (diff)
downloadlinux-c9dcb871b1a99301ba65685be95cbd93a5c540fe.tar.xz
iomap: don't search past page end in iomap_is_partially_uptodate
[ Upstream commit 3cc31fa65d85610574c0f6a474e89f4c419923d5 ] 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> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'fs/ocfs2')
0 files changed, 0 insertions, 0 deletions