| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1459522924-17720-1-git-send-email-tiwai@suse.de>
Date: Fri, 1 Apr 2016 17:02:04 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Jiri Slaby <jslaby@...e.cz>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: [PATCH v2] iov_iter: Fix out-of-bound access in iov_iter_advance()
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@...e.cz>
Signed-off-by: Takashi Iwai <tiwai@...e.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
Powered by blists - more mailing lists