Skip to content
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

Closed
ahh opened this issue Apr 11, 2017 · 3 comments
Closed

ASAN fails to detect alignment mismatched delete calls #799

ahh opened this issue Apr 11, 2017 · 3 comments
Assignees

Comments

@ahh
Copy link

ahh commented Apr 11, 2017

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.

@kcc
Copy link
Contributor

kcc commented Apr 11, 2017

we will need to intercept operator new/delete with the alignment argument and then store
the alignment in asan's ChunkHeader.
3 bits should be enough to represent 8 different alignment values: none, 8, 16, 32, 64, 128, 256, 512+.
We can steal 3 bits from u32 user_requested_size

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
@kcc
Copy link
Contributor

kcc commented Dec 11, 2017

@alekseyshl can we close this?

@alekseyshl
Copy link
Contributor

Yes, we can

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants