https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206551
--- Comment #2 from CTurt <ect...@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. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
