[cfe-dev] Potential frontend bug: heap-use-after-free in C++ coroutines

[Adrian Vogelsgesang via cfe-dev]

Please disregard – this mail has been delayed in the “mailing list moderation” for a while and is no longer relevant/was already addressed in a different thread

-Adrian

From: cfe-dev <cfe-dev-bounces at lists.llvm.org> on behalf of Adrian Vogelsgesang via cfe-dev <cfe-dev at lists.llvm.org>
Date: Wednesday, 10. February 2021 at 07:24
To: cfe-dev at lists.llvm.org <cfe-dev at lists.llvm.org>
Subject: [cfe-dev] Potential frontend bug: heap-use-after-free in C++ coroutines
Dear Clang community,

I think I stumbled across a front-end bug in clang’s C++ coroutine implementation.

Having an awaitable with

```
template<typename PROMISE> std::experimental::coroutine_handle<> await_suspend(std::experimental::coroutine_handle<PROMISE> coro) noexcept {
      coro.destroy();
     return std::experimental::noop_coroutine();
}
```

destroys the functions own coroutine frame. This is valid, as long as no-one afterwards resumes the coroutine anymore. However, address-sanitizer still reports a “heap-use-after-free” error.

>From my understanding so far, this is because the clang-frontend stores the return value of `await_suspend` in the coroutine frame. Instead, the clang-frontend should probably store this return value on the stack. Afaik, storing on the stack should be valid, as it is guaranteed that this return value will never live across a suspension point.

You can find a minimal repro in https://godbolt.org/z/eq6eoc<https://godbolt.org/z/eq6eoc> and a more complex end-to-end version in https://godbolt.org/z/8Yadv1<https://godbolt.org/z/8Yadv1> . See https://stackoverflow.com/questions/65991264/c-coroutines-is-it-valid-to-call-handle-destroy-from-the-final-suspend-poin<https://stackoverflow.com/questions/65991264/c-coroutines-is-it-valid-to-call-handle-destroy-from-the-final-suspend-poin> (in particular the comments to David Haim’s reply) for more context.

Cheers,
Adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210210/146c55ed/attachment.html>