Date: Sun, 24 Jan 2016 09:39:29 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 206551] Heap overflow in iconv kernel module Message-ID: <bug-206551-8-S0P8GGMmic@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-206551-8@https.bugs.freebsd.org/bugzilla/> References: <bug-206551-8@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206551 --- Comment #2 from CTurt <ecturt@gmail.com> --- It's worth noting that the minimum size which can be passed for a signed 32bit integer is `-0x7fffffff`, which wraps around to `0xffffffff80000001`. If on FreeBSD 9, when this size goes through `malloc` it will eventually be passed down to `uma_large_malloc`, which treats size as `vm_size_t`, a typedef for a 32bit unsigned integer, this means the size will truncate to `0x80000001` (just over 2GB). An allocation of 2GB is much more likely to succeed. And once it has succeeded, `copyin` will attempt to copy `0xffffffff80000001` bytes from userland into this allocation, which will clearly result in a heap overflow. The size of this heap overflow could be controlled by unmapping the page after the userland mapping, resulting in the function returning `EFAULT` once it has reached the end of the userland mapping. With a heap overflow of controllable size and contents, this bug shouldn't be difficult to exploit. I've demonstrated a similar exploit for PS4 kernel using `kevent` for heap layout manipulation primitives. Fortunately, for later versions of FreeBSD, the inner calls of `malloc` correctly handle `size` as 64bit types, which means the worst that can happen is the thread locking up whilst trying to allocate `0xffffffff80000001` bytes (because `M_WAITOK` is passed). -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-206551-8-S0P8GGMmic>