[llvm-bugs] [Bug 47475] New: [coroutines] Destroying a coroutine inside await_suspend with symmetric-transfer form hits asan use-after-free in non-optimized builds

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=47475

            Bug ID: 47475
           Summary: [coroutines] Destroying a coroutine inside
                    await_suspend with symmetric-transfer form hits asan
                    use-after-free in non-optimized builds
           Product: clang
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: lewissbaker at gmail.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

See https://godbolt.org/z/G7xM8G

The problem seems to be with the code generated for symmetric-transfer style
suspend-points (where await_suspend() returns a coroutine_handle to be
resumed).

Under non-optimised builds the compiler generates code that materializes the
returned coroutine_handle as a temporary in before then calling
__builtin_coro_resume() on its address. However, it materializes the
coroutine_handle using storage from the coroutine-frame rather than
materializing it on the stack.

For coroutines that destroy themselves inside await_suspend(), this results in
a use-after-free, as the compiler is trying to write the materialized
coroutine_handle to the now-freed coroutine frame upon return of
await_suspend().

It should instead be materializing the returned coroutine_handle on the stack.

This is unlikely to be an issue under optimised builds as the returned
coroutine_handle is generally kept in a register.

This seems to have been an issue since Clang 7, when symmetric-transfer was
first introduced.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200909/1d7a5b30/attachment.html>