** 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 fixed this issue: + 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 exist for this issue, and the patch - needs to be rework to applied to 5.4. + 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.
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. 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: New 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 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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2078659/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
