{"id":107233,"date":"2022-09-30T07:00:00","date_gmt":"2022-09-30T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107233"},"modified":"2022-09-30T07:17:25","modified_gmt":"2022-09-30T14:17:25","slug":"20220930-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220930-00\/?p=107233","title":{"rendered":"Debugging coroutine handles: Looking for the source of a one-byte memory corruption"},"content":{"rendered":"

A team was chasing a one-byte use-after-free memory corruption bug. These bugs are really frustrating to chase down because the memory corruption typically doesn’t trigger an immediate crash, but rather results in a delayed crash, which means that the culprit has done the damage and run away long before the problem is detected.<\/p>\n

We join the debugging session already in progress. We have determined that the corruption is to a memory block that previously contained a coroutine frame at offset 0xc0<\/code>.<\/p>\n

The state machine of a coroutine exists in the _ResumeCoro$2<\/code> function, so we can start there:<\/p>\n

contoso!DoStuffLater$_ResumeCoro$2:\r\n    mov     r11,rsp\r\n    ... stack frame nonsense ...\r\n\r\n    mov     rsi,rcx                 \/\/ rsi = coroutine frame pointer\r\n    mov     [rsp+28h],rcx\r\n    movzx   eax,word ptr [rcx+8]    \/\/ eax = coroutine state\r\n    mov     [rsp+20h],ax\r\n    inc     ax                      \/\/ artificially add 1\r\n    cmp     ax,8\r\n    ja      contoso!DoStuffLater$_ResumeCoro$2+0x3e5\r\n    ja      00007ffc`e777a5b5       \/\/ invalid index, die (jump to int 3)\r\n\r\n    movsx   rax,ax\r\n    lea     rdx,[contoso!__ImageBase]\r\n    mov     ecx,[rdx+rax*4+1BA5E0h] \/\/ look up jump table RVA\r\n    add     rcx,rdx                 \/\/ convert to absolute address\r\n    jmp     rcx                     \/\/ jump there\r\n\r\ncontoso!DoStuffLater$_ResumeCoro$2+0x3e5:\r\n    int     3\r\n<\/pre>\n
We see from the disassembly that the jump table starts at relative offset 0x1ba5e0<\/code>. We won’t dig into the jump table yet; let’s see if we can find the corruption point, which is a single-byte corruption at offset 0xc0<\/code> from the start of the coroutine frame. Maybe we’ll be lucky and the access is directly into the frame.<\/p>\n
0:026> #c0h contoso!DoStuffLater$_ResumeCoro$2\r\ncontoso!DoStuffLater$_ResumeCoro$2+0x136:\r\n    mov     [rsi+0C0h],al\r\n<\/pre>\n
Oh my goodness, we found a single-byte write at offset 0xc0<\/code> in the coroutine frame! Let’s see who is doing it.<\/p>\n
    mov     eax,6\r\n    mov     [rsi+8],ax\r\n\r\n    mov     rdx,rsi\r\n    mov     rcx,rbx\r\n    call    contoso!winrt::impl::notify_awaiter<`winrt::resume_foreground'::`2'::awaitable>::\r\n            await_suspend<std::experimental::coroutine_traits<winrt::fire_and_forget>::promise_type>\r\n    mov     [rsi+0C0h],al   \/\/ WRITE HAPPENS HERE\r\n<\/pre>\n
The first two instructions set the coroutine state to 6, which happens as part of coroutine suspension.<\/p>\n
The second group of instructions call the await_suspend<\/code> for a resume_foreground<\/code> awaiter. This is in code that is moving forward to state 6, and  we know that<\/a> the Microsoft compiler records coroutine states as even numbers starting at 2 (for the initial state), and then increases by two for each suspension point. Therefore, moving to state 6 means suspending for the second time.<\/p>\n
winrt::fire_and_forget DoStuffLater()\r\n{\r\n    co_await winrt::resume_after(100ms);\r\n    co_await winrt::resume_foreground(GetDispatcherQueue());\r\n    DoStuff();\r\n}\r\n<\/pre>\n
Okay, good, that second suspension theory lines up with the code: The second suspension is a call to resume_foreground<\/code>, and the code showed that we were calling resume_foreground<\/code>.<\/p>\n
And we see the bug: The code is storing the result of await_suspend<\/code> into the coroutine frame. This is something I called out in my  C++ coroutines: Getting started with awaitable objects<\/a> article:<\/p>\n
Therefore, it is important that your awaiter not use its this<\/code> pointer once it has arranged for the handle to be invoked somehow, because the this<\/code> pointer may no longer be valid.<\/p><\/blockquote>\n
In this case, not only did the awaiter get destructed, the entire coroutine frame was destructed!<\/p>\n
The compiler team confirmed that this is a known code-generation bug,  fixed in versions 16.11 and 17.0<\/a>.<\/p>\n
If you are stuck on 16.10 or older, you will have to work around the problem. From my investigation, it seems that the code generation problem occurs when you have an await_suspend<\/code> that returns bool<\/code>. In C++\/WinRT, there are only four places where this happens:<\/p>\n