<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=http://email.email.llvm.org/c/eJylVluP2jgU_jXwYoEgDJ3hgQe21UgjrbbSdld9HJ3EhngnsbO-wNBfv985CZBOq3alSohAEp_Ldzl26fV5-zQp7o9GlcY4dfLhxbqD8k6l2qh9_vJF_u7VZP3bZ4ptsq2ZrD9Mioc6pS5OVrtJ8YjPwaY6l_PKt_hTnpOpvDbUNJZcZXDrdFlbbCbFe0Xqsyl3MZq2bM4qZMfP1CnYlFCFderPHNNcfXSGc3MpiNx5Z1yKfOdSirJRxdx1PiSuk-LZVXXwzufYx3V8e5wLsUmd6IyglBSXpSpy6B4ZXDKvaRZPNlW10Xh1Rk7PfE5IOVd_1UjGn7ZrTItK8Ep22gSpr_ZeK6ys1d6WJkSVo1TE3cxSMIgfKOEboGAh4Jy8W1xQmcka3Pg1aB85Dy4tWYeLJIz40UcvNmOASbX2NeUgADPaKFUDwB6muZosPkwWu_57t0_okhdfW8JPakQf3L9XSASUgJTIhvPdcKJkoacn9W-21QvTIhGwyITggdSptlWt0JGKBgs0yHD2AE4QrqagJX6g6kVpf3JzRNI2Vv5oAt4VGikiZE2Rwwbroq1YFhw0KqD6_IznqBi1PsdEIT33HD9fYJfe37y4R5Ox_uZN1GLd3odWOr2-ftUwlYxCj8CgKDUoKkqa3GlKUrhR35PAoBPkqenY6yUKArWP7EhXMZxxrv7mMlIm5GhYzj4falygUG21cp6reJU0XQ7sECRF7MiFCGpj4wN5cDsfs355XgUjBROLNhKzqoLpfLTJh_NPFUuNea0CGE7ejdTa9ztj5mY2xmxk6WYQA3NJyKJzhcwCt8wBcaC8_F7kETtT2b1lkM69CrRHe9y8NnAKpKFQZ-4lOEiC6xz1OXwXO7VTUAdkhiwI6CtpG8kRpCdU_A2O2pY6XOa3pZ8ImF9XA3SHAcBSPt8c8ePXxdNDThLDjawUVS9Ho281ZPdNFb8TrwMK2QXTSKgOcr_M0C74fwSTIVFUrWnB4du-riR0nXEiPjZbQx0PDg50tCy8RpHWwUR4raMK47uGI-W5by7dCQgIUJrrSEGdnzFKzKBq9ObMaZx9KI8ZIwTsiWRUYOaikLizMu_3kI_M333jT3igqKp80DyiEHj3afcHslaECpRN6N3E3FIpVrHuJb4plDeSZDGDrDD3lROe3GB20T4cfuSQcAc7WpnX_j5Avs78DFG7mEIe9gnAF7kf3ki_53lYCJtbb0tWMJxyn8T7_2t-sXF4trTksljBOiaai3kzP24Dcq4-mNhZHjXggA1V-5M58kbxvm8XG437RkCHQO2gjz0grdl3b-XEpZyuFAN8nkkjFuknPLrxoLpm_ZoSeQR1kOzl16EsM6DfEwZieZTIiAMTNvCovDlNUkVMzoYHpmq8O8A__VkgWi0bzM2VfXeT1aP6GAbbcgEYt9wDwsu54mQuEREHhNCBaZBaeH9SX5Pfe0NON1B8CRmJF7kN0Rf4MgHaHTZR8NAv6-OhlqnervRmtaEpZVActuN5O82h2f5gNjfN8XKZDcMBf2XC8rlhvXrYLKf1dl2sNyu6Lxd6uX9YVovSLIrFfVGsabMuluV-2lBpmrjlQ01RsJuHIV1gd5j-egV2WywKfJbviuVqUyzmD-9oU-ni7m65vKf7YjG5Wxgcepo5x5n7cJiGrYQs8yHiYWNjireHOOXgfGGMFIwKk02N2Ta27M8zvGkx_qudehSwa9N0fKTTvvflcOLE_jQaVaCGxuRMpYmtdPAfgVD9Ow>53891</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            libfuzzer/asan: Fiber helpers don't support reallocation of a fiber stack
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          alexcrichton
      </td>
    </tr>
</table>

<pre>
    I've been working on the fuzzing of [Wasmtime](https://github.com/bytecodealliance/wasmtime), a WebAssembly runtime written in Rust. One of the components of Wasmtime is supporting asynchronously running WebAssembly in a way that wasm can be context-switched in-and-out of. This is implemented under the hood with fibers using an in-tree crate called [`wasmtime-fiber`](https://github.com/bytecodealliance/wasmtime/tree/main/crates/fiber) written in a mixture of Rust and assembly. 

After writing an initial fuzzer to test out the fiber implementation I quickly ran into errors which all seemed benign but hard to track down. I discovered that asan has intrinsics such as `__sanitizer_start_switch_fiber` and `__sanitizer_finish_switch_fiber` to inform the sanitizer runtime about fiber context switches and updated the `wasmtime-fiber` crate to have calls to those functions. Unfortuantely though this did not fix the purported crashes that I've been seeing.

 I've created a [sample repository](https://github.com/alexcrichton/wasmtime-fiber-asan-issue/) which has a reduced form of this issue, but specifically asan does not detect a situation such as:


* A stack is allocated for a fiber with `mmap`.
* Said stack is then used by the fiber.
* Said stack is then deallocated after the fiber is finished with `munmap`.
* Later an unrelated part of the project allocates memory with `mmap` which happens to overlap in the virtual address space where the old stack used to be. 
* Writes to this new `mmap` allocation are detected as "stack-buffer-underflow" according to ASAN because it presumably thinks the old stack is still in use.

In the sample above it's an example of using an un-instrumented version of `wasmtime-fiber` (one that doesn't call `__sanitizer_start_switch_fiber`) and manually injecting calls to those intrinsics. Despite this, however, the second part of the program which freshly allocates memory and writes to it is detected as a "stack-buffer-underflow" and crashes the program.

Is there away to inform asan that a stack has been entirely deallocate and should no longer be considered allocated memory? Or is there a different way we should be managing stacks in wasmtime-fiber to be compatible with asan's interpretation of fiber stacks?
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJylVl2P2kgQ_DXwMgKBIUt44IFLtFKk00W63CmPq7ZnwHNrz_jmA5b8-qtuG3A2URLpJITB9vRHdVXNlF5fdh8mxeZkVGmMU2cfnq07Ku9Uqo065C9f5O9BTd789plim2xrJm_eT4q3dUpdnKz2k-IRn6NNdS7nlW_xp7wkU3ltqGksucrg1vm6tthOineK1GdT7mM0bdlcVMiOn6lzsCmhCuvUnzmmufroDOfmUhC58864FPnOtRRlo4q563xIXCfFi6vq4J3PsY_r-PY4F2KTOtMFQSkpLktV5NA9MrhkXtIsnm2qaqPx6oycnvmckHKu_qqRjD9t15gWleCV7LQJUl_tvVZYWauDLU2IKkepiLuZpWAQP1DCN0DBQsA5eVhcUZnJGtz4f9A-ch5cWrIOF0kY8aOPXmzHAJNq7UvKQQBmtFGqBoA9THM1WbyfLPb99_6Q0CUvvrWEn9QIP7h_r5AIKAEpoQ3nu-NEyYJPH9S_2VbPPBaJgEUmBA-kzrWtaoWOVDRYoDEMZ4-YCcLVFLTED1Q9K-3Pbo5I2sbKn0zAuzJGighZU-SwwbpoK6YFB40KqD494TkqRq1PMVFIT_2Mn66wS--vXjygyVh_8yZqse7gQyud3l6_cZhKRqFHYGCUGhgVJU3uNCUp3KjvUWDgCfLUdOr5EgWB2kdWpKsYzjhXf3MZKRNyNExnn481LmCotlo5z1W8SJouB1YIkiJ25EIEtbHwgTxmOx9P_fq8CkYKJiZtJJ6qCqbz0SYfLj9lLDXmpQqYcPJuxNa-3xlPbmZjzEaWbgcy8CwJWXSukFngFh8QBcrL74QesTOVPVgG6dKzQHu0x81rA6WAGgp15p6CAyW4zlGfw3exV3sFdoBmyIKAvpK2kRxB-oGKvjGjtqUOl_l96ScC5rfVAN3BAJjKl7sifvy6aHrISSK4kZSi6ulo9L2G7L6p4nfidUAhu2AaCdWB7lcP7YL_RzAZEkXVmhYzfN3XbQhdZ5yQj8XWUMfGwYFOlonXKNI6mAitdVTBvmsoUp775tqdgIAApblZCur8DCsxA6vRmzPncfahPJ4YIWA_SEYFYi4KiTsr8-EA-oj_Hhp_xgNFVeWDZotC4P2n_R_IWhEqUDahdxNzS6VIxbrn-KpQ3kiShQdZmdxXSvjgBrEL96HwE4eEOljRyrz09wHyzfMzSO1iCnnYJwBf5H54I_2e5iEhbG69LJnBUMomifZ_yb9YOOwtLbksUrCOB83FvPKPu0HO1XsTO8tWgxmwoGp_NifeKN717WKjcd8Q6BioHfhxAKQ16-41nbiU823EAJ89aTRF-skc3dioblm_Hok8AjtI9vKbKYsH9HvCMFi2ErE4TMIGtsq70iRVhHM2bJiq8e4I_fRngWi1bDB3VfbdTVaP6mMYZMsFwG65B4SXc8XZXCMiDgZCRx6D1ML7k_p6-L025HQDxpegkWiR2xB-YV4mgLvDJoo59Mv6eKhlqncrvV1taZpsasyusWW_K7P1cpTVXj3Kkto0HR9MtO_ZNZyb4LIjwSEBjVNMc2h2P3D3pjldL7PBXvBXPJpPHm9Wb7fLab1bHsxmu9mY9UZrvV4taLUyD8vNdr0taL1dr6YNlaaJOz4WFQX7wWDzBfaXqd0ViwKf5UOxXG2LxfztA20rXazXy-WGNsVisl4YHHqaOdcx9-E4DTspqczHiIeNjSneH-KUg_OFMZIO8SlDHGE33qmmkn8n9f8Hznjnug">