New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ASAN fails to detect alignment mismatched delete calls #799
Comments
we will need to intercept operator new/delete with the alignment argument and then store |
dtzWill
pushed a commit
to llvm-mirror/compiler-rt
that referenced
this issue
Oct 25, 2017
ASan allocator stores the requested alignment for new and new[] calls and on delete and delete[] verifies that alignments do match. The representable alignments are: default alignment, 8, 16, 32, 64, 128, 256 and 512 bytes. Alignments > 512 are stored as 512, hence two different alignments > 512 will pass the check (possibly masking the bug), but limited memory requirements deemed to be a resonable tradeoff for relaxed conditions. The feature is controlled by new_delete_type_mismatch flag, the same one protecting new/delete matching size check. Differential revision: https://reviews.llvm.org/D38574 Issue: google/sanitizers#799 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@316595 91177308-0d34-0410-b5e6-96231b3b80d8
jyknight
pushed a commit
to jyknight/llvm-monorepo
that referenced
this issue
Oct 30, 2017
ASan allocator stores the requested alignment for new and new[] calls and on delete and delete[] verifies that alignments do match. The representable alignments are: default alignment, 8, 16, 32, 64, 128, 256 and 512 bytes. Alignments > 512 are stored as 512, hence two different alignments > 512 will pass the check (possibly masking the bug), but limited memory requirements deemed to be a resonable tradeoff for relaxed conditions. The feature is controlled by new_delete_type_mismatch flag, the same one protecting new/delete matching size check. Differential revision: https://reviews.llvm.org/D38574 Issue: google/sanitizers#799 llvm-svn=316595
@alekseyshl can we close this? |
Yes, we can |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
class alignas(64) Foo {
char buf[64];
};
class Bar {
char buf[64];
};
Foo *f = new Foo;
Bar *b = new Bar;
volatile Foo *nf = reinterpret_cast<Foo *>(b);
volatile Bar *nb = reinterpret_cast<Bar *>(f);
DoNotOptimize(nf); // prevent new/delete elision somehow
DoNotOptimize(nb);
delete nf;
delete nb;
This does not error out. At least as of C++17, I believe it should be able to make it do so (and that it is important to in fact do so)--becuase the "delete nf" call should invoke a aligned delete operator (3 or 7 here http://en.cppreference.com/w/cpp/memory/new/operator_delete) and the delete nb call should not.
The text was updated successfully, but these errors were encountered: