Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1637790 > unrolled thread

[PATCH] FS: fix stack-out-of-bounds wanning

Back to article view | Back to linux.kernel

Contents

  [PATCH] FS: fix stack-out-of-bounds wanning Shaohua Li <shli@fb.com> - 2017-05-09 01:50 +0200
    Re: [PATCH] FS: fix stack-out-of-bounds wanning Al Viro <viro@ZenIV.linux.org.uk> - 2017-05-09 02:30 +0200

#1637790 — [PATCH] FS: fix stack-out-of-bounds wanning

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

[toc] | [next] | [standalone]

#1637797

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web