Re: [git pull] vfs part 2

Andrey Ryabinin
2015-04-23T10:16:26Z

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);