Concurrent removals of certain anonymous shared memory mappings by using the UMTX_SHM_DESTROY sub-request of UMTX_OP_SHM can lead to decreasing the reference count of the object representing the mapping too many times, causing it to be freed too early. A malicious code exercizing the UMTX_SHM_DESTROY sub-request in parallel can panic the kernel or enable further Use-After-Free attacks, potentially including code execution or Capsicum sandbox escape.