Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754683AbbHQJSQ (ORCPT ); Mon, 17 Aug 2015 05:18:16 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:34034 "EHLO mail-lb0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751334AbbHQJSP (ORCPT ); Mon, 17 Aug 2015 05:18:15 -0400 Subject: Re: fs: out of bounds on stack in iov_iter_advance To: Chuck Ebbert , Sasha Levin References: <55CB5484.6080000@oracle.com> <20150815161338.4ea210ff@as> Cc: Al Viro , linux-fsdevel , LKML From: Andrey Ryabinin Message-ID: <55D1A6D4.3080605@gmail.com> Date: Mon, 17 Aug 2015 12:18:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150815161338.4ea210ff@as> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4324 Lines: 94 On 08/15/2015 11:13 PM, Chuck Ebbert wrote: > On Wed, 12 Aug 2015 10:13:24 -0400 > Sasha Levin 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/