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,