From: Takashi Iwai <tiwai@suse.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jiri Slaby <jslaby@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH v2] iov_iter: Fix out-of-bound access in iov_iter_advance()
Date: Fri, 1 Apr 2016 17:02:04 +0200 [thread overview]
Message-ID: <1459522924-17720-1-git-send-email-tiwai@suse.de> (raw)
Currently, iov_iter_advance() just calls iterate_and_advance() macro
as is, even if size=0 is passed. Usually it is OK to pass size=0 to
the macro. However, when the iov_iter has been already advanced to
the end of the array, it may lead to an out-of-bound access, since the
macro always reads the length of the vector at first. This bug is
actually seen via KASAN with net tun driver, for example.
BUG: KASAN: stack-out-of-bounds in iov_iter_advance+0x510/0x540 at addr ffff88003d5efd40
Read of size 8 by task syz-executor/22356
page:ffffea0000f57bc0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x1fffff80000000()
page dumped because: kasan: bad access detected
CPU: 0 PID: 22356 Comm: syz-executor Tainted: G W E 4.4.6-0-default #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.1-0-g4adadbd-20151112_172657-sheep25 04/01/2014
0000000000000000 ffff88003d5ef9d0 ffffffff819f42c1 ffff88003d5efa68
ffff88003d5efd40 0000000000000000 ffff88003d5efd38 ffff88003d5efa58
ffffffff815f7267 000000000000000a ffff88003d5efad8 0000000000000296
Call Trace:
[<ffffffff819f42c1>] ? dump_stack+0xb3/0x112
[<ffffffff815f7267>] ? kasan_report_error+0x507/0x540
[<ffffffff8157359f>] ? __might_fault+0x3f/0x50
[<ffffffff815f73d3>] ? __asan_report_load8_noabort+0x43/0x50
[<ffffffff81a30660>] ? iov_iter_advance+0x510/0x540
[<ffffffff81a30660>] ? iov_iter_advance+0x510/0x540
[<ffffffffa0e08c15>] ? tun_get_user+0x745/0x21a0 [tun]
[<ffffffff812791f0>] ? debug_check_no_locks_freed+0x290/0x290
[<ffffffffa0e084d0>] ? tun_select_queue+0x370/0x370 [tun]
[<ffffffff81329559>] ? futex_wake+0x149/0x420
[<ffffffff812c9027>] ? debug_lockdep_rcu_enabled+0x77/0x90
[<ffffffffa0e03895>] ? __tun_get+0x5/0x220 [tun]
[<ffffffffa0e039b1>] ? __tun_get+0x121/0x220 [tun]
[<ffffffffa0e0a88a>] ? tun_chr_write_iter+0xda/0x190 [tun]
[<ffffffff8164841a>] ? __vfs_write+0x30a/0x480
[<ffffffff81648110>] ? vfs_iter_write+0x320/0x320
[<ffffffff812c9027>] ? debug_lockdep_rcu_enabled+0x77/0x90
[<ffffffff818c1448>] ? common_file_perm+0x158/0x7a0
[<ffffffff818c1cb7>] ? apparmor_file_permission+0x27/0x30
[<ffffffff81648fa5>] ? rw_verify_area+0x105/0x2f0
[<ffffffff8164960c>] ? vfs_write+0x16c/0x4a0
[<ffffffff8164c29a>] ? SyS_write+0x11a/0x230
This patch adds the proper check of the size to iov_iter_advance(),
like all other functions calling iterate_and_advance() macro.
Reported-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
We can put these checks in iterate_and_advance(), too. I chose this
patch since it's smaller, and doing in the macro will be a bit ugly.
Let me know if you prefer another option.
v1->v2: Fix the bogus return value
lib/iov_iter.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/lib/iov_iter.c b/lib/iov_iter.c
index 5fecddc32b1b..2545c31fa0de 100644
--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -508,6 +508,10 @@ EXPORT_SYMBOL(iov_iter_copy_from_user_atomic);
void iov_iter_advance(struct iov_iter *i, size_t size)
{
+ if (unlikely(size > i->count))
+ size = i->count;
+ if (unlikely(!size))
+ return;
iterate_and_advance(i, size, v, 0, 0, 0)
}
EXPORT_SYMBOL(iov_iter_advance);
--
2.7.4
next reply other threads:[~2016-04-01 15:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 15:02 Takashi Iwai [this message]
2016-04-01 17:39 ` [PATCH v2] iov_iter: Fix out-of-bound access in iov_iter_advance() Al Viro
2016-04-01 18:39 ` Takashi Iwai
2016-04-01 19:21 ` Al Viro
2016-04-01 20:11 ` Takashi Iwai
2016-04-07 9:20 ` Takashi Iwai
2016-04-14 12:37 ` Takashi Iwai
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=1459522924-17720-1-git-send-email-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=akpm@linux-foundation.org \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.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.