Date: Mon, 25 Jan 2016 16:22:16 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 206585] hpt_set_info possible buffer overflow Message-ID: <bug-206585-8-WpxfVWMrp3@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-206585-8@https.bugs.freebsd.org/bugzilla/> References: <bug-206585-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=3D206585 CTurt <ecturt@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|Not A Bug |--- Status|Closed |Open --- Comment #2 from CTurt <ecturt@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)) <=3D 0x1000 ) { ptr =3D malloc((unsigned int)(*((_DWORD *)&hptproc_buffer + 4) + *((_DW= ORD *)&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)) <=3D 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 manipula= te the heap layout to reliably target the overflow. --=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-206585-8-WpxfVWMrp3>