NACK/Cmt: [SRU][F][PATCH 0/1] UBUNTU: SAUCE: Hold IOPOLL locks when triggering io_uring's deferred work
Thibault Ferrante
thibault.ferrante at canonical.com
Mon Sep 2 12:32:56 UTC 2024
The cover letter subject should be the CVE number as `[SRU][F][PATCH 0/1] CVE-2023-21400`
And should also be appended to the commit, see [1]
1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fb348857e7b67eefe365052f1423427b66dedbf3
On 02-09-2024 10:09, Chengen Du 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.
If you cherry pick an upstream commit, keep it's title and don't modify it (UBUNTU: SAUCE: shouldn't be there.)
If there is nothing left from upstream anymore, don't keep upstream reference as Signoff and other fields.
>
> [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(+)
>
--
--
Thibault
More information about the kernel-team
mailing list