mirror of
https://github.com/reactos/reactos.git
synced 2025-04-18 11:36:46 +00:00
00c69bcd15
On a x86 system aligning the return length pointer to a 4-byte boundary works best since pointers in general are 4-byte aligned for x86 systems. However, what happens on a AMD64 system is that we still align this pointer to 4-byte, ObjectTypeInfo is a 8-byte pointer and we might write into the return length past the 4-byte boundary. If one were to allocate a pool of memory with that length and query all the object types info and free the said pool of memory thereafter, the system will crash with BAD_POOL_HEADER because ObQueryTypeInfo overwrote the return length past the 4-byte boundary length therefore leading up with corrupted memory blocks in the pool header. This symptom of BAD_POOL_HEADER happens exactly the same in Windows Server 2003 x64 Edition. Newer versions of Windows like 10 aren't affected. But, Windows has another bug where they are using MaximumLength for the calculation of the needed length to be returned to caller. MaximumLength does not guarantee you that it includes the NULL-terminator in the length and that potentially leads to a buffer overrun. Also annotate the ObQueryTypeInfo function with SAL2. https://processhacker.sourceforge.io/doc/object_8c_source.html (read the comment in KphObjectTypeInformation). |
||
|---|---|---|
| .. | ||
| cache | ||
| cc | ||
| config | ||
| dbgk | ||
| ex | ||
| fsrtl | ||
| fstub | ||
| inbv | ||
| include | ||
| io | ||
| kd | ||
| kd64 | ||
| kdbg | ||
| ke | ||
| lpc | ||
| mm | ||
| ntkrnlmp | ||
| ob | ||
| po | ||
| ps | ||
| rtl | ||
| se | ||
| tests | ||
| vdm | ||
| vf | ||
| wmi | ||
| CMakeLists.txt | ||
| guid.c | ||
| KrnlFun.c | ||
| ntdll.S | ||
| ntos.cmake | ||
| ntoskrnl.rc | ||
| ntoskrnl.spec | ||
| sysfuncs.lst | ||