[Bug 206585] hpt_set_info possible buffer overflow

[bugzilla-noreply at freebsd.org]

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

CTurt <ecturt at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|Not A Bug                   |---
             Status|Closed                      |Open

--- Comment #2 from CTurt <ecturt at gmail.com> ---
Not sure what I was talking about earlier, but I've decompiled the module to
produce more easily analysable code:

if ( (unsigned int)(*((_DWORD *)&hptproc_buffer + 4) + *((_DWORD
*)&hptproc_buffer + 7)) <= 0x1000 )
  {
    ptr = malloc((unsigned int)(*((_DWORD *)&hptproc_buffer + 4) + *((_DWORD
*)&hptproc_buffer + 7)));
    if ( ptr )
    {
      if ( *((_DWORD *)&hptproc_buffer + 4) )
        copyin(*((_QWORD *)&hptproc_buffer + 1), ptr, *((_DWORD
*)&hptproc_buffer + 4));

Now it's clear that the comparison on the sum of the two sizes is treated as
`unsigned int`.

So, theoretically:

`nInBufferSize` of `0xffffffff`,

`nOutBufferSize` of `1`,

The sum of these two sizes will overflow to `0`, so the check will pass:

if ( (unsigned int)(*((_DWORD *)&hptproc_buffer + 4) + *((_DWORD
*)&hptproc_buffer + 7)) <= 0x1000 )

The size passed to `malloc` will also be `0`.

However, `copyin` will copy from `nInBufferSize` of `0xffffffff`.

To exploit this, the size of the allocation could be controlled to manipulate
the heap layout to reliably target the overflow.

-- 
You are receiving this mail because:
You are the assignee for the bug.