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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206551 --- Comment #2 from CTurt <ecturt@gmail.com> --- It's worth noting that the minimum size which can be passed for a signed 32= bit 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 type= def for a 32bit unsigned integer, this means the size will truncate to `0x80000= 001` (just over 2GB). An allocation of 2GB is much more likely to succeed. And once it has succee= ded, `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 af= ter the userland mapping, resulting in the function returning `EFAULT` once it = has reached the end of the userland mapping. With a heap overflow of controllab= le 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 happ= en is the thread locking up whilst trying to allocate `0xffffffff80000001` byt= es (because `M_WAITOK` is passed). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-206551-8-S0P8GGMmic>