From 590447888e1b2d49a2c00344acff63fe3ca8153c Mon Sep 17 00:00:00 2001 From: Timo Kreuzer Date: Tue, 20 May 2014 21:11:43 +0000 Subject: [PATCH] [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. svn path=/trunk/; revision=63388 --- reactos/ntoskrnl/mm/ARM3/virtual.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/reactos/ntoskrnl/mm/ARM3/virtual.c b/reactos/ntoskrnl/mm/ARM3/virtual.c index 935fc971dda..3eef793fcd9 100644 --- a/reactos/ntoskrnl/mm/ARM3/virtual.c +++ b/reactos/ntoskrnl/mm/ARM3/virtual.c @@ -4593,8 +4593,8 @@ NtAllocateVirtualMemory(IN HANDLE ProcessHandle, // on the user input, and then compute the actual region size once all the // alignments have been done. // - StartingAddress = (ULONG_PTR)PAGE_ALIGN(PBaseAddress); EndingAddress = (((ULONG_PTR)PBaseAddress + PRegionSize - 1) | (PAGE_SIZE - 1)); + StartingAddress = (ULONG_PTR)PAGE_ALIGN(PBaseAddress); PRegionSize = EndingAddress - StartingAddress + 1; // @@ -4700,6 +4700,12 @@ NtAllocateVirtualMemory(IN HANDLE ProcessHandle, { // // 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,