Author: tkreuzer
Date: Tue May 20 21:11:43 2014
New Revision: 63388
URL:
http://svn.reactos.org/svn/reactos?rev=63388&view=rev
Log:
[NTOSKRNL]
Fix ending address calculation for the commit path in NtAllocateVirtualMemory like done
for the reserve path in r63356. Add a comment about a Windows kernel bug, which we will
keep for now, until the implications are better determined.
Modified:
trunk/reactos/ntoskrnl/mm/ARM3/virtual.c
Modified: trunk/reactos/ntoskrnl/mm/ARM3/virtual.c
URL:
http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/virtual.c…
==============================================================================
--- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Tue May 20 21:11:43 2014
@@ -4593,8 +4593,8 @@
// on the user input, and then compute the actual region size once all the
// alignments have been done.
//
+ EndingAddress = (((ULONG_PTR)PBaseAddress + PRegionSize - 1) | (PAGE_SIZE - 1));
StartingAddress = (ULONG_PTR)PAGE_ALIGN(PBaseAddress);
- EndingAddress = (((ULONG_PTR)PBaseAddress + PRegionSize - 1) | (PAGE_SIZE - 1));
PRegionSize = EndingAddress - StartingAddress + 1;
//
@@ -4700,6 +4700,12 @@
{
//
// Make sure it's okay to touch it
+ // Note: The Windows 2003 kernel has a bug here, passing the
+ // unaligned base address together with the aligned size,
+ // potentially covering a region larger than the actual allocation.
+ // Might be exposed through NtGdiCreateDIBSection w/ section handle
+ // For now we keep this behavior.
+ // TODO: analyze possible implications, create test case
//
Status = MiCheckSecuredVad(FoundVad,
PBaseAddress,