diff options
author | Eric Sandeen <sandeen@redhat.com> | 2018-12-21 19:42:50 +0300 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2019-01-26 11:32:43 +0300 |
commit | c9dcb871b1a99301ba65685be95cbd93a5c540fe (patch) | |
tree | 161b3884cffc79c31413f082132b06e16a445d85 /fs/ocfs2 | |
parent | 00886cebcce534ad228d9530fc8df56af666ccc5 (diff) | |
download | linux-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