From owner-freebsd-bugs@freebsd.org Sun Jan 24 09:39:30 2016 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2EFF57393 for ; Sun, 24 Jan 2016 09:39:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F6A5A8E for ; Sun, 24 Jan 2016 09:39:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u0O9dTLr025279 for ; Sun, 24 Jan 2016 09:39:29 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 206551] Heap overflow in iconv kernel module Date: Sun, 24 Jan 2016 09:39:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ecturt@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2016 09:39:30 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206551 --- Comment #2 from CTurt --- 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.=