Recently vulnerability information disclosed (CVE-2022-29582) in the implementation of the io_uring asynchronous I/O interface, included in the Linux kernel since version 5.1, which allows an unprivileged user to become root on the system, even when executing a container exploit.
It is worth mentioning that said vulnerability was reported just over 3 months ago (approximately early May this year), but full information and disclosure was only recently released.
Regarding vulnerability, it is mentioned that this occurs when accessing a block of memory already freed, manifests itself in Linux kernels starting with the 5.10 branch.
About vulnerability CVE-2022-29582
This vulnerability allows access to freed memory as a result of a race condition when handling timeouts in the io_flush_timeouts() function, whiche removes the timeout entry from the list and cancels it, without verifying the creation and deletion of the timeout at that point.
An updated general description of io_uring has already been provided by others. They explain it a thousand times better than we do, so we'll just cover the subsystem more extensively (see this Grapl Security article and this Flatt Security article for a great introduction).
What is more important, the opcode field determines what type of operation to perform. For each "opcode" that requires it, the fd field specifies the file descriptor on which to perform the requested I/O. Almost all normal I/O system calls (read, sendto, etc.) have an equivalent asynchronous opcode. Each field can take on different roles depending on the operation.
Once retrieved from the SQ, an SQE is converted to an internal representation described by struct io_kiocb( kernel input/output call back). These objects are commonly known as requests.
struct io_kiocb is used as an equivalent to the SQE "ready-for-launch" on which it is based, whereby any file descriptor is resolved to struct file*s, user credentials are attached, personality (in which cores will run), etc.
After the requested operation is complete, it is written to the completion queue (CQ) an entry that corresponds to the SQE. Such an entry is called a completion queue entry (CQE) and contains fields such as an error code and a result value. The user space application can poll the CQ for new entries to determine if the sent SQEs have finished processing and what their result was.
It is mentioned that there are some scenarios in which it is easy to replace an object on the progress. But there are two limitations:
- LT' has to be assigned and initialized in a race window. That is, after the LT is released but before reaching a point in the LT that is no longer accessed.
- LT' can only be another struct io_kiocb object. Due to heap isolation, where objects in the heap are separated according to their type, it is too difficult to reassign them as a different type of object within the race window.
Researchers have prepared a functional exploit which does not require the inclusion of user identifier namespaces (user namespaces) for its operation and can provide root access to the host when an unprivileged user launches the exploit in an isolated container.
Our exploit targets kernel version 5.10.90, the version Google was remotely running at the time. We had to adjust our exploit to the particular specifications of the server (4 Skylake Xeon cores @ 2.80Ghz, 16GiB RAM), but with some tweaking, any machine running a vulnerable kernel should be exploitable.
The exploit also works in the nsjail environment isolated on Google COS (Container Optimized OS) distribution based on Chromium OS and used on Google Cloud Platform on Compute Engine virtual machines. The exploit is designed to work with kernel branches from 5.10 to 5.12. Lastly, it is worth mentioning that the problem fixed in April in updates 5.10.111, 5.15.34 and 5.17.3.
Finally, if you are interested in knowing more about the vulnerability, you can consult the publication made In the following link.