A use-after-free flaw was found in io_grab_files in fs/io_uring.c in io_uring I/O access. This flaw could allow a local attacker with a user privilege to crash the system at device IORING_OP_CLOSE operation where a file reference counter was not incremented while in use. This vulnerability could even lead to a kernel information leak problem.
Acknowledgments: Name: Ryota Shiga (Flatt Security)
Mitigation: Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
Statement: The affected code was not introduced into any kernel versions shipped with Red Hat Enterprise Linux making this vulnerable not applicable to these platforms.
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1925426]
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2021-20226
Hi Do you have any reference to the upstream changes which addressed this issue? Cf. my followup on the post to oss-security as https://www.openwall.com/lists/oss-security/2021/02/05/7. Regards, Salvatore
Hello Salvatore The affected source in fs/io_uring.c was last modified with 233295130e53 patch in the upstream from v5.10 onwrd as a "clean up code", where the affected source was removed from the later versions of this tree. (As this was reported for 5.7.0) ~~~~ static int io_grab_files(struct io_kiocb *req) { int ret =3D -EBADF; struct io_ring_ctx *ctx =3D req->ctx; if (req->work.files || (req->flags & REQ_F_NO_FILE_TABLE)) return 0; if (!ctx->ring_file) return -EBADF; rcu_read_lock(); spin_lock_irq(&ctx->inflight_lock); /* * We use the f_ops->flush() handler to ensure that we can flush * out work accessing these files if the fd is closed. Check if * the fd has changed since we started down this path, and disallow * this operation if it has. */ if (fcheck(ctx->ring_fd) =3D=3D ctx->ring_file) { list_add(&req->inflight_entry, &ctx->inflight_list); req->flags |=3D REQ_F_INFLIGHT; req->work.files =3D current->files; <-- referened but did not update reference count ret =3D 0; } spin_unlock_irq(&ctx->inflight_lock); rcu_read_unlock(); return ret; } ~~~ $ git show 233295130e53 commit 233295130e53c8dfe6dbef3f52634c3f7e44cd6a Author: Pavel Begunkov <asml.silence> Date: Sat Oct 10 18:34:06 2020 +0100 io_uring: clean up ->files grabbing Move work.files grabbing into io_prep_async_work() to all other work resources initialisation. We don't need to keep it separately now, as ->ring_fd/file are gone. It also allows to not grab it when a request is not going to io-wq. .. $ git tag --contains 233295130e53 v5.10 v5.10-rc1 v5.10-rc2 v5.10-rc3 v5.10-rc4 v5.10-rc5 v5.10-rc6 v5.10-rc7 v5.11-rc1 v5.11-rc2 v5.11-rc3 v5.11-rc4 v5.11-rc5 v5.11-rc6 v5.11-rc7 This flaw is identified as a use-after-free problem, which may escalate privileges with good knowledge of kernel debug information. There was no shipped RHEL kernel version were seen affected with this problem.
Thank you! Possible to clarify this as well directly on https://www.openwall.com/lists/oss-security/2021/02/05/7 ?
This issue was fixed for Fedora with the 5.10 kernel rebases.