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

Groups > linux.kernel > #1206149 > unrolled thread

fs: out of bounds on stack in iov_iter_advance

Started bySasha Levin <sasha.levin@oracle.com>
First post2015-08-12 16:20 +0200
Last post2015-08-19 07:50 +0200
Articles 4 — 4 participants

Back to article view | Back to linux.kernel

Contents

  fs: out of bounds on stack in iov_iter_advance Sasha Levin <sasha.levin@oracle.com> - 2015-08-12 16:20 +0200
    Re: fs: out of bounds on stack in iov_iter_advance Chuck Ebbert <cebbert.lkml@gmail.com> - 2015-08-15 22:20 +0200
      Re: fs: out of bounds on stack in iov_iter_advance Andrey Ryabinin <ryabinin.a.a@gmail.com> - 2015-08-17 11:20 +0200
        Re: fs: out of bounds on stack in iov_iter_advance Al Viro <viro@ZenIV.linux.org.uk> - 2015-08-19 07:50 +0200

#1206149 — fs: out of bounds on stack in iov_iter_advance

FromSasha Levin <sasha.levin@oracle.com>
Date2015-08-12 16:20 +0200
Subjectfs: out of bounds on stack in iov_iter_advance
Message-ID<pWF2P-6ON-29@gated-at.bofh.it>
Hi all,

While fuzzing with trinity inside a KVM tools guest running -next I've stumbled on the following:

[64092.216447] ==================================================================
[64092.217840] BUG: KASan: out of bounds on stack in iov_iter_advance+0x3b7/0x480 at addr ffff88040506fd48
[64092.219314] Read of size 8 by task trinity-c194/11387
[64092.220114] page:ffffea0010141bc0 count:0 mapcount:0 mapping:          (null) index:0x2
[64092.221354] flags: 0x46fffff80000000()
[64092.221998] page dumped because: kasan: bad access detected
[64092.222879] CPU: 4 PID: 11387 Comm: trinity-c194 Not tainted 4.2.0-rc6-next-20150810-sasha-00040-g12ad0db3-dirty #2427
[64092.224537]  ffff88040506fd30 ffff88040506fa88 ffffffff9ce7763b ffff88040506fb10
[64092.225763]  ffff88040506fb00 ffffffff9376b1be 0000000000000000 ffff880270108600
[64092.226992]  0000000000000282 0000000000000000 0000000000000000 0000000000000000
[64092.228221] Call Trace:
[64092.228679] dump_stack (lib/dump_stack.c:52)
[64092.231252] kasan_report_error (mm/kasan/report.c:132 mm/kasan/report.c:193)
[64092.232219] __asan_report_load8_noabort (mm/kasan/report.c:251)
[64092.234167] iov_iter_advance (lib/iov_iter.c:511)
[64092.235105] generic_file_read_iter (mm/filemap.c:1743)
[64092.241532] blkdev_read_iter (fs/block_dev.c:1649)
[64092.242448] __vfs_read (fs/read_write.c:423 fs/read_write.c:434)
[64092.246949] vfs_read (fs/read_write.c:454)
[64092.247743] SyS_pread64 (fs/read_write.c:607 fs/read_write.c:594)
[64092.250445] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
[64092.251440] Memory state around the buggy address:
[64092.252221]  ffff88040506fc00: 00 00 00 f1 f1 f1 f1 00 00 00 00 00 f4 f4 f4 f3
[64092.253340]  ffff88040506fc80: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00
[64092.254456] >ffff88040506fd00: 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2 00 00
[64092.255566]                                               ^
[64092.256432]  ffff88040506fd80: 00 00 00 f4 f4 f4 f2 f2 f2 f2 00 00 00 00 00 f4
[64092.257557]  ffff88040506fe00: f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
[64092.258684] ==================================================================


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1208152

FromChuck Ebbert <cebbert.lkml@gmail.com>
Date2015-08-15 22:20 +0200
Message-ID<pXQ5P-3xm-1@gated-at.bofh.it>
In reply to#1206149
On Wed, 12 Aug 2015 10:13:24 -0400
Sasha Levin <sasha.levin@oracle.com> wrote:

> While fuzzing with trinity inside a KVM tools guest running -next I've stumbled on the following:
> 
> [64092.216447] ==================================================================
> [64092.217840] BUG: KASan: out of bounds on stack in iov_iter_advance+0x3b7/0x480 at addr ffff88040506fd48
> [64092.219314] Read of size 8 by task trinity-c194/11387
> [64092.220114] page:ffffea0010141bc0 count:0 mapcount:0 mapping:          (null) index:0x2
> [64092.221354] flags: 0x46fffff80000000()
> [64092.221998] page dumped because: kasan: bad access detected
> [64092.222879] CPU: 4 PID: 11387 Comm: trinity-c194 Not tainted 4.2.0-rc6-next-20150810-sasha-00040-g12ad0db3-dirty #2427
> [64092.224537]  ffff88040506fd30 ffff88040506fa88 ffffffff9ce7763b ffff88040506fb10
> [64092.225763]  ffff88040506fb00 ffffffff9376b1be 0000000000000000 ffff880270108600
> [64092.226992]  0000000000000282 0000000000000000 0000000000000000 0000000000000000
> [64092.228221] Call Trace:
> [64092.228679] dump_stack (lib/dump_stack.c:52)
> [64092.231252] kasan_report_error (mm/kasan/report.c:132 mm/kasan/report.c:193)
> [64092.232219] __asan_report_load8_noabort (mm/kasan/report.c:251)
> [64092.234167] iov_iter_advance (lib/iov_iter.c:511)
> [64092.235105] generic_file_read_iter (mm/filemap.c:1743)
> [64092.241532] blkdev_read_iter (fs/block_dev.c:1649)
> [64092.242448] __vfs_read (fs/read_write.c:423 fs/read_write.c:434)
> [64092.246949] vfs_read (fs/read_write.c:454)
> [64092.247743] SyS_pread64 (fs/read_write.c:607 fs/read_write.c:594)
> [64092.250445] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
> [64092.251440] Memory state around the buggy address:
> [64092.252221]  ffff88040506fc00: 00 00 00 f1 f1 f1 f1 00 00 00 00 00 f4 f4 f4 f3
> [64092.253340]  ffff88040506fc80: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00
> [64092.254456] >ffff88040506fd00: 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2 00 00
> [64092.255566]                                               ^
> [64092.256432]  ffff88040506fd80: 00 00 00 f4 f4 f4 f2 f2 f2 f2 00 00 00 00 00 f4
> [64092.257557]  ffff88040506fe00: f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
> [64092.258684] ==================================================================
> 

I tried to debug this but kasan doesn't print much useful information
for stack out of bounds access. It shows the address that's being
accessed but it doesn't show the value of the boundary that was
exceeded. And the stack dump doesn't show any addresses either - just
contents. It would be nice to see a full stack frame dump showing
where all the parent frames are too. Also too the file and line number
(lib/iov_iter.c:511) are completely useless because of inlining,
though that's not kasan's fault.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1208488

FromAndrey Ryabinin <ryabinin.a.a@gmail.com>
Date2015-08-17 11:20 +0200
Message-ID<pYoKd-2ZR-15@gated-at.bofh.it>
In reply to#1208152

On 08/15/2015 11:13 PM, Chuck Ebbert wrote:
> On Wed, 12 Aug 2015 10:13:24 -0400
> Sasha Levin <sasha.levin@oracle.com> wrote:
> 
>> While fuzzing with trinity inside a KVM tools guest running -next I've stumbled on the following:
>>
>> [64092.216447] ==================================================================
>> [64092.217840] BUG: KASan: out of bounds on stack in iov_iter_advance+0x3b7/0x480 at addr ffff88040506fd48
>> [64092.219314] Read of size 8 by task trinity-c194/11387
>> [64092.220114] page:ffffea0010141bc0 count:0 mapcount:0 mapping:          (null) index:0x2
>> [64092.221354] flags: 0x46fffff80000000()
>> [64092.221998] page dumped because: kasan: bad access detected
>> [64092.222879] CPU: 4 PID: 11387 Comm: trinity-c194 Not tainted 4.2.0-rc6-next-20150810-sasha-00040-g12ad0db3-dirty #2427
>> [64092.224537]  ffff88040506fd30 ffff88040506fa88 ffffffff9ce7763b ffff88040506fb10
>> [64092.225763]  ffff88040506fb00 ffffffff9376b1be 0000000000000000 ffff880270108600
>> [64092.226992]  0000000000000282 0000000000000000 0000000000000000 0000000000000000
>> [64092.228221] Call Trace:
>> [64092.228679] dump_stack (lib/dump_stack.c:52)
>> [64092.231252] kasan_report_error (mm/kasan/report.c:132 mm/kasan/report.c:193)
>> [64092.232219] __asan_report_load8_noabort (mm/kasan/report.c:251)
>> [64092.234167] iov_iter_advance (lib/iov_iter.c:511)
>> [64092.235105] generic_file_read_iter (mm/filemap.c:1743)
>> [64092.241532] blkdev_read_iter (fs/block_dev.c:1649)
>> [64092.242448] __vfs_read (fs/read_write.c:423 fs/read_write.c:434)
>> [64092.246949] vfs_read (fs/read_write.c:454)
>> [64092.247743] SyS_pread64 (fs/read_write.c:607 fs/read_write.c:594)
>> [64092.250445] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
>> [64092.251440] Memory state around the buggy address:
>> [64092.252221]  ffff88040506fc00: 00 00 00 f1 f1 f1 f1 00 00 00 00 00 f4 f4 f4 f3
>> [64092.253340]  ffff88040506fc80: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00
>> [64092.254456] >ffff88040506fd00: 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2 00 00
>> [64092.255566]                                               ^
>> [64092.256432]  ffff88040506fd80: 00 00 00 f4 f4 f4 f2 f2 f2 f2 00 00 00 00 00 f4
>> [64092.257557]  ffff88040506fe00: f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
>> [64092.258684] ==================================================================
>>
> 
> I tried to debug this but kasan doesn't print much useful information
> for stack out of bounds access. It shows the address that's being
> accessed but it doesn't show the value of the boundary that was
> exceeded.

This could be estimated by looking at the shadow memory:

	ffff88040506fd00: 00 00 f1 f1 f1 f1 00 00 f4 [f4] f2 f2 f2 f2 00 00

Each byte in shadow represents 8 bytes of memory. So f1 - is the left redzone of the stack frame.
2 zeroes is probably 'struct iovec iov' defined in new_sync_read(). The next two f4 is redzone.
We hit the second f4, which means that we accessed iov[1].iov_len

This bug is similar to recently found bug in 9p: http://thread.gmane.org/gmane.linux.kernel/1931799/focus=1936542

Such report could be produced if retval > count.

generic_file_read_iter():
...
	size_t count = iov_iter_count(iter);
...
	if (!count)
		goto out; /* skip atime */
	size = i_size_read(inode);
	retval = filemap_write_and_wait_range(mapping, pos,
				pos + count - 1);
	if (!retval) {
		struct iov_iter data = *iter;
		retval = mapping->a_ops->direct_IO(iocb, &data, pos);
	}

	if (retval > 0) {
		*ppos = pos + retval;
		iov_iter_advance(iter, retval);


So either filemap_write_and_wait_range() or mapping->a_ops->direct_IO() returned more
than 'count'.


> And the stack dump doesn't show any addresses either - just
> contents. It would be nice to see a full stack frame dump showing
> where all the parent frames are too. 

Yes, I think it might be helpful to dump some portion of stack around the access address.

> Also too the file and line number
> (lib/iov_iter.c:511) are completely useless because of inlining,
> though that's not kasan's fault.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1209632

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2015-08-19 07:50 +0200
Message-ID<pZ4q6-59O-5@gated-at.bofh.it>
In reply to#1208488
On Mon, Aug 17, 2015 at 12:18:12PM +0300, Andrey Ryabinin wrote:

> This bug is similar to recently found bug in 9p: http://thread.gmane.org/gmane.linux.kernel/1931799/focus=1936542

Ow.  For those who'd missed that fun: the bug in question had turned out to
be caused by improper reuse of request ids, _not_ in the call chain of
the triggering syscall.

> 	if (!retval) {
> 		struct iov_iter data = *iter;
> 		retval = mapping->a_ops->direct_IO(iocb, &data, pos);
> 	}
> 
> 	if (retval > 0) {
> 		*ppos = pos + retval;
> 		iov_iter_advance(iter, retval);
> 
> 
> So either filemap_write_and_wait_range()
	Shouldn't - it's supposed to return 0 or -E...

> or mapping->a_ops->direct_IO() returned more
> than 'count'.

	Was there DAX involved?  ->direct_IO() in there is blkdev_direct_IO(),
which takes rather different paths in those cases...

> > Also too the file and line number
> > (lib/iov_iter.c:511) are completely useless because of inlining,
> > though that's not kasan's fault.

Might make sense to slap
	if (WARN_ON(size > iov_iter_count(i)))
		print size and *i
and see if it triggers...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web