[Bug 206551] Heap overflow in iconv kernel module

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206551

--- Comment #2 from CTurt <ecturt at 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.