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

[Chengen Du]

I apologize, I forgot to update the cover letter subject. Please
kindly disregard this one.

On Fri, Sep 27, 2024 at 1:31 PM Chengen Du <chengen.du at canonical.com> wrote:
>
> 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
>