This problem was accidentally discovered by the internal symbolizer, but
it's relevant for external one as well, see the test.
If we just disable tagging, there may still be tagged allocations that
have already been freed. After disabling tagging, these tagged
allocations can be released to the user as-is, which would later break
the "invalid-free" check.
We cannot just disable the "invalid-free" check with disabled tagging,
because if we re-enable tagging, the issue still applies to allocations
created when it was disabled.
The fix is to continue tagging with zero even if tagging is disabled.
This makes the "disabled" mode less efficient, but this is not the
primary use case.
This matches behaviour of asan. sanitizer_common/TestCases/malloc_hook.cpp
should've caught this- but hwasan was on XFAIL.
Differential Revision: https://reviews.llvm.org/D151580
The primary motivation for this change is to allow FreeHooks to obtain
the allocated size of the pointer being freed in a fast, efficient manner.
Differential Revision: https://reviews.llvm.org/D151360
__sanitizer_get_current_allocated_bytes had as body, but allocator
caches were not registered to collect stats. It's done by
SizeClassAllocator64LocalCache::Init().
Reviewed By: thurston
Differential Revision: https://reviews.llvm.org/D151389
Ensures a subsequent call (via an external caller) to
__sanitizer_get_allocated_size via hooks will return a valid size.
This allows a faster version of __sanitizer_get_allocated_size
to be implemented, which can skip checks.
Test to ensure RunFreeHooks' call order will come with
__sanitizer_get_allocated_size_fast
Differential Revision: https://reviews.llvm.org/D151151
For primary use-case when !HWASAN_ALIASING_MODE the function is constant
true and should be eliminated by optimizations.
In case HWASAN_ALIASING_MODE all new calls to the functions were missing
in the first place. We just not use this mode for anything but tests, so
we didn't noticed.
Addressing @thurston comment on D149293
Reviewed By: thurston
Differential Revision: https://reviews.llvm.org/D149305
The secondary allocator calls mmap which should return zero-inited pages, so we
don't need to explicitly memset it with zeros. This is similar to what asan's
calloc does.
Differential Revision: https://reviews.llvm.org/D149285
D147005 introduced __sanitizer_get_allocated_begin, with a return
value of void*. This involved a few naughty casts that dropped the
const. This patch adds back the const qualifier.
Differential Revision: https://reviews.llvm.org/D147489
After D143438 there is no point in this check as the size will never 0. Also this keeps it consistent with ASAN where there is not size check in LsanMetadata::allocated.
Reviewed By: MaskRay, vitalybuka
Differential Revision: https://reviews.llvm.org/D143442
For HWASAN this would be the tagged address. It is the same pointer when pointer tagging is not used. Coincidently this also fixes some test which rely on comparing pointers.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D143121
Unlike asan, we can't use pointer arithmetics to get from user ptr to
metadata. Asan does not use CombinedAllocator::GetMetadata and store
metadata next to the user data.
Please note that that this code is not used. It will be connected at some point when the rest of the code is ready.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D139464
This came up during review of D139464. Looks like this filed is always set to false to it is basically unused.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D139654
In that case it is very likely that there will be a tag mismatch anyway.
We handle the case that the pointer belongs to neither of the allocators
by getting a nullptr from allocator.GetBlockBegin.
Reviewed By: hctim, eugenis
Differential Revision: https://reviews.llvm.org/D108383
Fixes a regression when the allocator is disabled, and a dirty
allocation is re-used. This only occurs when the allocator is disabled,
so a test-only fix, but still necessary.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D108650
In that case it is very likely that there will be a tag mismatch anyway.
We handle the case that the pointer belongs to neither of the allocators
by getting a nullptr from allocator.GetBlockBegin.
Reviewed By: hctim, eugenis
Differential Revision: https://reviews.llvm.org/D108383
The shadow for a short granule is stored in the last byte of the
granule. Currently, if there's a tail-overwrite report (a
buffer-overflow-write in uninstrumented code), we report the shadow byte
as a mismatch against the magic.
Fix this bug by slapping the shadow into the expected value. This also
makes sure that if the uninstrumented WRITE does clobber the shadow
byte, it reports the shadow was actually clobbered as well.
Reviewed By: eugenis, fmayer
Differential Revision: https://reviews.llvm.org/D107938
Before this change we were locking the StackDepot in the fork()
interceptor. This results in a deadlock when allocator functions are
used in a pthread_atfork() callback.
Instead, set up a pthread_atfork() callback at init that locks/unlocks
both StackDepot and the allocator. Since our callback is set up very
early, the pre-fork callback is executed late, and both post-fork ones
are executed early, which works perfect for us.
Differential Revision: https://reviews.llvm.org/D108063
This moves logic for setting kAliasRegionStart into hwasan_allocator.cpp
so other platforms that do not support aliasing mode will not need to define
kAliasRegionStart.
Differential Revision: https://reviews.llvm.org/D105725
Short granule tags as poison cause a UaF to read the referenced
memory to retrieve the tag, and means we do not detect the UaF
if the last granule's tag is still around.
This only increases the change of not catching a UaF from
0.39 % (1 / 256) to 0.42 % (1 / (256 - 17)).
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D104304
Userspace page aliasing allows us to use middle pointer bits for tags
without untagging them before syscalls or accesses. This should enable
easier experimentation with HWASan on x86_64 platforms.
Currently stack, global, and secondary heap tagging are unsupported.
Only primary heap allocations get tagged.
Note that aliasing mode will not work properly in the presence of
fork(), since heap memory will be shared between the parent and child
processes. This mode is non-ideal; we expect Intel LAM to enable full
HWASan support on x86_64 in the future.
Reviewed By: vitalybuka, eugenis
Differential Revision: https://reviews.llvm.org/D98875
Userspace page aliasing allows us to use middle pointer bits for tags
without untagging them before syscalls or accesses. This should enable
easier experimentation with HWASan on x86_64 platforms.
Currently stack, global, and secondary heap tagging are unsupported.
Only primary heap allocations get tagged.
Note that aliasing mode will not work properly in the presence of
fork(), since heap memory will be shared between the parent and child
processes. This mode is non-ideal; we expect Intel LAM to enable full
HWASan support on x86_64 in the future.
Reviewed By: vitalybuka, eugenis
Differential Revision: https://reviews.llvm.org/D98875
