Re: [git pull] vfs part 2

[Andrey Ryabinin]

On 04/23/2015 01:16 PM, Andrey Ryabinin wrote:
> On 04/15/2015 09:14 PM, Al Viro wrote:
>>       9p: switch p9_client_write() to passing it struct iov_iter *
> 
> Hi Al,
> 
> This change caused following:
> 
> [   91.637917] ==================================================================
> [   91.639252] BUG: KASan: out of bounds on stack in iov_iter_advance+0x3e4/0x4b0 at addr ffff8800ba1efd20
> [   91.640979] Read of size 8 by task trinity-c15/4746
> [   91.641493] page:ffffea0002e87bc0 count:0 mapcount:0 mapping:          (null) index:0x0
> [   91.641787] flags: 0x100000000000000()
> [   91.641787] page dumped because: kasan: bad access detected
> [   91.641787] CPU: 1 PID: 4746 Comm: trinity-c15 Not tainted 4.0.0+ #319
> [   91.641787] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014
> [   91.641787]  ffff8800ba1efd08 ffff8800ba1ef918 ffffffff81ab94ed 1ffffd40005d0f7f
> [   91.641787]  ffff8800ba1ef9b0 ffff8800ba1ef998 ffffffff812bc0f4 ffffffff814901f0
> [   91.641787]  ffff8800ba1efa40 0000000000000296 ffff8801f4993490 ffffffff81228fe0
> [   91.641787] Call Trace:
> [   91.641787] dump_stack (lib/dump_stack.c:52)
> [   91.641787] kasan_report_error (mm/kasan/report.c:132 mm/kasan/report.c:193)
> [   91.641787] ? idr_mark_full (lib/idr.c:551)
> [   91.641787] ? clear_exceptional_entry (mm/truncate.c:561)
> [   91.641787] __asan_report_load8_noabort (mm/kasan/report.c:251)
> [   91.641787] ? iov_iter_advance (lib/iov_iter.c:511)
> [   91.641787] iov_iter_advance (lib/iov_iter.c:511)
> [   91.641787] p9_client_write (net/9p/client.c:1656)
> [   91.641787] ? p9_client_readdir (net/9p/client.c:1614)
> [   91.641787] ? kasan_kmalloc (mm/kasan/kasan.c:355)
> [   91.641787] ? __kmalloc (mm/slub.c:3325)
> [   91.641787] ? p9_client_readdir (net/9p/client.c:1614)
> [   91.641787] ? v9fs_file_lock_dotl (fs/9p/vfs_file.c:405)
> [   91.641787] v9fs_file_write_iter (fs/9p/vfs_file.c:421)
> [   91.641787] ? __sb_end_write (fs/super.c:1192)
> [   91.641787] ? v9fs_file_lock_dotl (fs/9p/vfs_file.c:405)
> [   91.641787] ? do_readv_writev (fs/read_write.c:776)
> [   91.641787] ? recalc_sigpending (kernel/signal.c:160)
> [   91.641787] ? __set_task_blocked (kernel/signal.c:2514)
> [   91.641787] __vfs_write (fs/read_write.c:479 fs/read_write.c:490)
> [   91.641787] ? recalc_sigpending (kernel/signal.c:160)
> [   91.641787] ? __vfs_read (fs/read_write.c:486)
> [   91.641787] ? __sb_end_write (fs/super.c:1192)
> [   91.641787] ? signal_setup_done (kernel/signal.c:2556)
> [   91.641787] ? hrtimer_start (kernel/time/hrtimer.c:1043)
> [   91.641787] ? do_setitimer (kernel/time/itimer.c:222)
> [   91.641787] vfs_write (include/linux/fs.h:1984 include/linux/fs.h:2416 fs/read_write.c:543)
> [   91.641787] SyS_write (fs/read_write.c:585 fs/read_write.c:576)
> [   91.641787] ? SyS_read (fs/read_write.c:576)
> [   91.641787] ? init_fpu (arch/x86/kernel/i387.c:231 arch/x86/kernel/i387.c:266)
> [   91.641787] ? math_state_restore (arch/x86/kernel/traps.c:869)
> [   91.641787] system_call_fastpath (arch/x86/kernel/entry_64.S:261)
> [   91.641787] Memory state around the buggy address:
> [   91.641787]  ffff8800ba1efc00: f2 00 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f3 f3 f3
> [   91.641787]  ffff8800ba1efc80: f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1
> [   91.641787] >ffff8800ba1efd00: f1 00 00 f4 f4 f2 f2 f2 f2 00 00 00 00 00 f4 f4
> [   91.641787]                                ^
> [   91.641787]  ffff8800ba1efd80: f4 f2 f2 f2 f2 00 00 00 00 00 f4 f4 f4 f3 f3 f3
> [   91.641787]  ffff8800ba1efe00: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   91.641787] ==================================================================
> 
> 
> 
> This could happen when p9pdu_readf() changes 'count' to some value > iov_iter_count(from):
> 
> p9_client_write():
> <...>
> 		int count = iov_iter_count(from);
> <...>
> 		*err = p9pdu_readf(req->rc, clnt->proto_version, "d", &count);
> <...>
> 		iov_iter_advance(from, count);
> 
> 
> 

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