Make sure the address range for poisoned memory is protected

NEW
Unassigned

Status

()

defect
4 years ago
2 years ago

People

(Reporter: erahm, Unassigned)

Tracking

(Blocks 1 bug, {sec-want})

Firefox Tracking Flags

(Not tracked)

Details

+++ This bug was initially created as a clone of Bug #1108045 +++

Bug 860254 made it possible to only poison freed memory but not uninitialized memory on optimized builds.

The original request included the following requirement:

> Ideally, would like the poison address to be in a non-addressable block of memory. On Windows, we would try to MEM_RESERVE the 32k page block at 0xFAFAFAFA or another poison block.

AFAICT that was never done (in this case we're talking about 0x5a5a5a5a). If it has we can close this bug, if not we should take whatever steps are necessary to protect that region.

Comment 1

4 years ago
I could have sworn I had filed this, but I can't find it.

Yes we should do this. We should probably try and unify this with the layout poison area: the big difference is that requires the poison area to include the value 0xMNMNMNMN for some value MN... so we'd have to go looking around to find an appropriate poison area in case the VM space at 0x5A5A5A5A is already mapped.

Updated

3 years ago
Keywords: sec-want
glandium pointed out the poison value is now 0xe5, so on Linux at least 0xe5e5e5e5 on 32-bit is in the reserved kernel space as is 0xe5e5e5e5e5e5e5e5 on 64-bit. We should still double-check this on macOS and Windows.

Also note with have a mechinism for reserving the mozPoisonValue [1], this could probably be reused if necessary.

[1] http://searchfox.org/mozilla-central/rev/d30462037ffea383e74c42542c820cf65b2b144e/mfbt/Poison.cpp#156-200
You need to log in before you can comment on or make changes to this bug.