From 15779f70b9425e2191c59908d699ae5437a9b9fc Mon Sep 17 00:00:00 2001 From: Ingo Weinhold Date: Wed, 20 Jan 2010 09:00:38 +0000 Subject: [PATCH] vm_get_page_mapping(): The translation map wasn't locked. For x86 the function is used only in one place and the missing locking would be harmless if it weren't for the per translation map physical page mapper. It is used to map the page table for the lookup. Concurrent access could corrupt its data structures, or, just as bad, the unlocked Query() could remap the page table used by a concurrent Map() or Unmap(), which would then manipulate the wrong page table. Potentially messing up kernel memory, this bug could obviously cause all kinds of kernel crashes and weird behavior. E.g. ticket #5138 is a likely candidate, as are triple faults. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35195 a95241bf-73f2-0310-859d-f6bbb57e9c96 --- src/system/kernel/vm/vm.cpp | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/system/kernel/vm/vm.cpp b/src/system/kernel/vm/vm.cpp index b2759a713c..4e18918625 100644 --- a/src/system/kernel/vm/vm.cpp +++ b/src/system/kernel/vm/vm.cpp @@ -2090,9 +2090,12 @@ vm_get_page_mapping(team_id team, addr_t vaddr, addr_t* paddr) if (addressSpace == NULL) return B_BAD_TEAM_ID; + VMTranslationMap* map = addressSpace->TranslationMap(); + + map->Lock(); uint32 dummyFlags; - status_t status = addressSpace->TranslationMap()->Query(vaddr, paddr, - &dummyFlags); + status_t status = map->Query(vaddr, paddr, &dummyFlags); + map->Unlock(); addressSpace->Put(); return status;