At its core, a simple, yet odd Linux kernel issue, __io_req_init_async assumes that the new request (req) being submitted was submitted by its own worker, so it sets the req->work.identity to current->io_uring.

The problem is that this is not always the case, multiple tasks can submit requests to the same io_uring at the same time that can end up in the same work queue but associated with different request tasks. This then becomes a vulnerability in io_put_identity which checks if the request’s work identity matches the tasks identity. If they don’t match it uses that as a cue to mean the identity should have its ref count decremented and possibly free’d. Leading to an invalid free because of the wrong identity being used.

Definitely, an interesting primitive to have, the post continues on into exploitation locally, including some novel strategies and some challenges with the kCTF environment.