linux-kernel - Re: fs: out of bounds on stack in iov_iter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Aug 2015 12:18:12 +0300
From:	Andrey Ryabinin <ryabinin.a.a@...il.com>
To:	Chuck Ebbert <cebbert.lkml@...il.com>,
	Sasha Levin <sasha.levin@...cle.com>
Cc:	Al Viro <viro@...IV.linux.org.uk>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: fs: out of bounds on stack in iov_iter_advance



On 08/15/2015 11:13 PM, Chuck Ebbert wrote:
> On Wed, 12 Aug 2015 10:13:24 -0400
> Sasha Levin <sasha.levin@...cle.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/