[Bug 2078659] Re: Hold IOPOLL locks when triggering io_uring's deferred work

** Description changed:

[Impact]
io_commit_cqring() writes the CQ ring tail to make it visible and also triggers any deferred work.
When a ring is set up with IOPOLL, it doesn't require locking around the CQ ring updates.
However, if there is deferred work that needs processing, io_queue_deferred() assumes that the completion_lock is held.
The io_uring subsystem does not properly handle locking for rings with IOPOLL, leading to a double-free vulnerability, which can be exploited as CVE-2023-21400.

[Fix]
There is a commit that fixed this issue.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fb348857e7b67eefe365052f1423427b66dedbf3

There is no direct upstream commit for this issue, and the patch needs
to be reworked to apply to version 5.4.

[Test Plan]
- This is a timing issue that can be verified by testing the normal behavior.
- The test should cover the exact call path and ensure that no deadlock occurs.
- For the userspace program, you can implement it using the liburing library and choose the XFS filesystem, as it implements the iopoll function hook.
- The io_uring_params flag should be set to (IORING_SETUP_SQPOLL | IORING_SETUP_IOPOLL) and use O_DIRECT to open the XFS file for reading operations.
- The test should be executed multiple times to ensure that no deadlocks occur.
+ This is a timing issue that can be triggered by using the liburing library to implement a test program.
+ First, set the io_uring_params flag to IORING_SETUP_IOPOLL and open an XFS file with the O_RDWR | O_DIRECT flags, as the XFS filesystem implements the iopoll function hook.
+ After setting up io_uring, create two threads in the process: one thread will wait for completion queue events, and the other will continuously send readv and writev requests in sequence.
+ The writev requests should include the IOSQE_IO_DRAIN flag to ensure that previous submission queue events are completed first.
+
+ The issue arises when writev requests add entries into the defer_list,
+ but the io_iopoll_complete function consumes entries from defer_list
+ without holding the appropriate lock.

[Where problems could occur]
The problematic call path can be triggered under specific usage scenarios and only affects io_uring functionality.
If the patch contains any issues, it may lead to a deadlock.

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2078659

Title:
Hold IOPOLL locks when triggering io_uring's deferred work

Status in linux package in Ubuntu:
New
Status in linux source package in Focal:
In Progress

Bug description:
[Impact]
io_commit_cqring() writes the CQ ring tail to make it visible and also triggers any deferred work.
When a ring is set up with IOPOLL, it doesn't require locking around the CQ ring updates.
However, if there is deferred work that needs processing, io_queue_deferred() assumes that the completion_lock is held.
The io_uring subsystem does not properly handle locking for rings with IOPOLL, leading to a double-free vulnerability, which can be exploited as CVE-2023-21400.

[Fix]
There is a commit that fixed this issue.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fb348857e7b67eefe365052f1423427b66dedbf3

There is no direct upstream commit for this issue, and the patch needs
to be reworked to apply to version 5.4.

[Test Plan]
This is a timing issue that can be triggered by using the liburing library to implement a test program.
First, set the io_uring_params flag to IORING_SETUP_IOPOLL and open an XFS file with the O_RDWR | O_DIRECT flags, as the XFS filesystem implements the iopoll function hook.
After setting up io_uring, create two threads in the process: one thread will wait for completion queue events, and the other will continuously send readv and writev requests in sequence.
The writev requests should include the IOSQE_IO_DRAIN flag to ensure that previous submission queue events are completed first.

The issue arises when writev requests add entries into the defer_list,
but the io_iopoll_complete function consumes entries from defer_list
without holding the appropriate lock.

[Where problems could occur]
The problematic call path can be triggered under specific usage scenarios and only affects io_uring functionality.
If the patch contains any issues, it may lead to a deadlock.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2078659/+subscriptions