From: Andrey Ryabinin <a.ryabinin@samsung.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [git pull] vfs part 2
Date: Thu, 23 Apr 2015 13:16:15 +0300 [thread overview]
Message-ID: <5538C66F.4050404@samsung.com> (raw)
In-Reply-To: <20150415181406.GL889@ZenIV.linux.org.uk>
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);
next prev parent reply other threads:[~2015-04-23 10:16 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-15 18:14 [git pull] vfs part 2 Al Viro
2015-04-23 10:16 ` Andrey Ryabinin [this message]
2015-05-25 8:30 ` Andrey Ryabinin
2015-06-21 21:12 ` Al Viro
2015-06-21 21:12 ` Al Viro
2015-06-21 21:16 ` Linus Torvalds
2015-06-21 21:16 ` Linus Torvalds
2015-06-21 21:35 ` Al Viro
2015-06-21 21:35 ` Al Viro
2015-06-22 12:02 ` Andrey Ryabinin
2015-06-22 12:02 ` Andrey Ryabinin
2015-07-01 6:27 ` Al Viro
2015-07-01 7:50 ` Andrey Ryabinin
2015-07-01 8:27 ` Al Viro
2015-07-01 8:41 ` Andrey Ryabinin
2015-07-01 8:55 ` Al Viro
2015-07-01 11:25 ` Andrey Ryabinin
2015-07-01 18:44 ` Al Viro
2015-07-02 3:20 ` Al Viro
2015-07-02 4:10 ` running out of tags in 9P (was Re: [git pull] vfs part 2) Al Viro
2015-07-02 7:50 ` Andrey Ryabinin
2015-07-02 7:50 ` Andrey Ryabinin
2015-07-02 7:59 ` Al Viro
2015-07-02 7:59 ` Al Viro
2015-07-02 8:19 ` Andrey Ryabinin
2015-07-02 8:25 ` Al Viro
2015-07-02 8:42 ` Al Viro
2015-07-02 8:42 ` Al Viro
2015-07-02 12:19 ` Andrey Ryabinin
2015-07-02 12:19 ` Andrey Ryabinin
2015-07-02 16:43 ` Al Viro
2015-07-02 16:43 ` Al Viro
2015-07-02 16:49 ` Al Viro
2015-07-02 16:49 ` Al Viro
2015-07-03 8:19 ` Andrey Ryabinin
2015-07-03 8:19 ` Andrey Ryabinin
2015-07-03 9:42 ` Al Viro
2015-07-03 15:00 ` [PATCH] forgetting to cancel request in interrupted zero-copy 9P RPC " Al Viro
2015-07-03 15:00 ` Al Viro
2015-07-03 19:56 ` Andrey Ryabinin
2015-07-03 19:56 ` Andrey Ryabinin
2015-07-02 20:26 ` running out of tags in 9P " Andrey Ryabinin
[not found] ` <5594E5EB.4030808@samsung.com>
2015-07-02 7:50 ` Al Viro
2015-07-02 12:00 ` [git pull] vfs part 2 Jeff Layton
2015-07-02 12:07 ` Jeff Layton
2015-07-02 16:45 ` Al Viro
2015-07-02 17:01 ` Jeff Layton
2015-07-02 17:56 ` Dominique Martinet
2015-07-02 18:43 ` Al Viro
2015-07-02 21:00 ` Dominique Martinet
2015-07-02 18:59 ` Jeff Layton
2015-07-02 20:36 ` Andrey Ryabinin
2015-07-02 18:40 ` Al Viro
2015-07-02 19:16 ` Linus Torvalds
2015-07-02 20:44 ` Al Viro
-- strict thread matches above, loose matches on Subject: below --
2012-03-31 5:19 Al Viro
2012-03-31 18:28 ` Linus Torvalds
2012-03-31 18:28 ` Linus Torvalds
2012-03-31 18:31 ` Linus Torvalds
2012-03-31 18:57 ` Al Viro
2012-03-31 19:29 ` Linus Torvalds
2012-03-31 19:29 ` Linus Torvalds
2012-03-31 19:39 ` Al Viro
2012-03-31 19:42 ` Al Viro
2012-03-31 19:48 ` Linus Torvalds
2012-03-31 20:08 ` Al Viro
2012-03-31 21:37 ` Linus Torvalds
2010-03-05 16:29 Al Viro
2010-03-05 19:53 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5538C66F.4050404@samsung.com \
--to=a.ryabinin@samsung.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.