* [PATCH] FS: fix stack-out-of-bounds wanning
@ 2017-05-08 23:42 Shaohua Li
2017-05-09 0:26 ` Al Viro
0 siblings, 1 reply; 2+ messages in thread
From: Shaohua Li @ 2017-05-08 23:42 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, Kernel-team, Al Viro
I'm seeing below with lastet upstream. Commit
5ecda13(generic_file_read_iter(): make use of iov_iter_revert())
directly pass iter to ->direct_IO(), ->direct_io already advances count
bytes but return -EIOCBQUEUED. In this case, count is bigger than
iov_iter_count(iter). We really want to revert count -
iov_iter_count(iter) instead of the opposite.
[ 5754.726656] ==================================================================
[ 5754.727246] BUG: KASAN: stack-out-of-bounds in iov_iter_revert+0x14b/0x450
[ 5754.727708] Read of size 8 at addr ffff880115247cb8 by task fio/1563
[ 5754.728502] CPU: 1 PID: 1563 Comm: fio Not tainted 4.11.0+ #1394
[ 5754.728506] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-5.el7_3.2 04/01/2014
[ 5754.728509] Call Trace:
[ 5754.728520] dump_stack+0x67/0x92
[ 5754.728529] print_address_description+0xd9/0x270
[ 5754.728536] ? iov_iter_revert+0x14b/0x450
[ 5754.728542] kasan_report+0x265/0x350
[ 5754.728551] __asan_load8+0x5e/0x70
[ 5754.728555] iov_iter_revert+0x14b/0x450
[ 5754.728562] ? filemap_check_errors+0x41/0x80
[ 5754.728572] generic_file_read_iter+0xb16/0x1030
[ 5754.728578] ? mark_held_locks+0x23/0xc0
[ 5754.728584] ? depot_save_stack+0x1d2/0x470
[ 5754.728592] ? _raw_spin_unlock_irqrestore+0x36/0x50
[ 5754.728599] ? trace_hardirqs_on_caller+0x186/0x260
[ 5754.728604] ? trace_hardirqs_on+0xd/0x10
[ 5754.728612] ? depot_save_stack+0x34a/0x470
[ 5754.728622] ? generic_file_write_iter+0x2b0/0x2b0
[ 5754.728627] ? mark_lock+0x6d/0x850
[ 5754.728632] ? save_stack_trace+0x1b/0x20
[ 5754.728636] ? save_stack+0x46/0xd0
[ 5754.728641] ? mark_lock+0x6d/0x850
[ 5754.728649] ? import_single_range+0xfb/0x140
[ 5754.728685] blkdev_read_iter+0x7d/0x90
[ 5754.728693] aio_read+0x1be/0x200
FIx: 5ecda13(generic_file_read_iter(): make use of iov_iter_revert())
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Shaohua Li <shli@fb.com>
---
mm/filemap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index 681da61..df227638 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2050,7 +2050,7 @@ generic_file_read_iter(struct kiocb *iocb, struct iov_iter *iter)
iocb->ki_pos += retval;
count -= retval;
}
- iov_iter_revert(iter, iov_iter_count(iter) - count);
+ iov_iter_revert(iter, count - iov_iter_count(iter));
/*
* Btrfs can have a short DIO read if we encounter
--
2.9.3
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] FS: fix stack-out-of-bounds wanning
2017-05-08 23:42 [PATCH] FS: fix stack-out-of-bounds wanning Shaohua Li
@ 2017-05-09 0:26 ` Al Viro
0 siblings, 0 replies; 2+ messages in thread
From: Al Viro @ 2017-05-09 0:26 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-kernel, akpm, Kernel-team
On Mon, May 08, 2017 at 04:42:50PM -0700, Shaohua Li wrote:
> I'm seeing below with lastet upstream. Commit
> 5ecda13(generic_file_read_iter(): make use of iov_iter_revert())
> directly pass iter to ->direct_IO(), ->direct_io already advances count
> bytes but return -EIOCBQUEUED. In this case, count is bigger than
> iov_iter_count(iter). We really want to revert count -
> iov_iter_count(iter) instead of the opposite.
Already discussed; the patch in my tree is that braino fix + sanity check
in iov_iter_revert(), to prevent anything similar in the future.
The reason it wasn't caught in tests (without KASAN, that is) is that
to get really obvious breakage out of that, you need a short read from
->direct_IO() *and* fallback to cached read after it. -EIOCBQUEUED
obviously excludes the latter, so the bug is almost certain to remain quiet.
There is a non-zero chance of actually running into unmapped memory while
doing that iov_iter_revert(), but it's fairly low. Unfortunately, since
that allowed the damn thing to remain unnoticed...
Will be in tonight's pull request.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-05-09 0:26 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-08 23:42 [PATCH] FS: fix stack-out-of-bounds wanning Shaohua Li
2017-05-09 0:26 ` Al Viro
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.