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
This commit is contained in:
Ingo Weinhold 2010-01-20 09:00:38 +00:00
parent 28e27159b9
commit 15779f70b9

View File

@ -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;