On recent OS X systems, blocks used as callbacks for XPC events (set up e.g. via xpc_connection_set_event_handler) are not later executed via the public libdispatch API (dispatch_async, etc). Because we don't intercept the path where the block is executed, we can fail to register the newly created dispatch thread. To fix that, let's intercept libxpc's APIs that take a block as a callback handler, and let's wrap these blocks in the same way as we do for libdispatch API.
Details
Details
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
Comment Actions
How does this test check that the underlying thread(s) has been correctly registered?
Should we make the callback crash to make sure the report is correct?
lib/asan/asan_mac.cc | ||
---|---|---|
47 ↗ | (On Diff #33562) | While at it, can you please fix the inclusion order? |
test/asan/TestCases/Darwin/xpc_interceptors.mm | ||
29 ↗ | (On Diff #33562) | Why pass trace[0] to fprintf here? |
Comment Actions
__asan_get_alloc_stack will internally try to retrieve the thread from ThreadRegistry, which will currently (without the patch) crash.
Comment Actions
Updating patch to perform a buffer overflow in the XPC callback thread. Added comment explaining the bug. Fixed inclusion order.
Comment Actions
LGTM if xpc.h available on all OSX versions for which ASan is supported.
lib/asan/asan_mac.cc | ||
---|---|---|
47 ↗ | (On Diff #34134) | Is this header available on all OSX versions we're targeting? |