[SRU][F][PATCH 0/1] UBUNTU: SAUCE: Hold IOPOLL locks when triggering io_uring's deferred work

[Chengen Du]

BugLink: https://bugs.launchpad.net/bugs/2078659

SRU Justification:

[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.

[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.

Jens Axboe (1):
  io_uring: ensure IOPOLL locks around deferred work

 fs/io_uring.c | 4 ++++
 1 file changed, 4 insertions(+)

-- 
2.43.0