Bug 1873476 (CVE-2021-20226)

Summary: CVE-2021-20226 kernel: use-after-free in io_uring feature
Product: [Other] Security Response Reporter: Guilherme de Almeida Suckevicz <gsuckevi>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: acaringi, adscvr, airlied, alciregi, bhu, blc, bmasney, brdeoliv, bskeggs, carnil, chwhite, dhoward, dramseur, dvlasenk, esammons, fhrbata, hdegoede, hkrzesin, iboverma, itamar, jarodwilson, jeremy, jforbes, jglisse, jhunter, jlelli, jminter, jmoyer, jonathan, josef, jross, jshortt, jstancek, jwboyer, kcarcia, kernel-maint, kernel-mgr, kmitts, lgoncalv, linville, masami256, matt, mchehab, mcressma, mgala, mjudeiki, mlangsdo, nmurray, pmatouse, ptalbert, qzhao, rkeshri, rt-maint, rvrbovsk, security-response-team, steved, walters, williams
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: kernel 5.10 Doc Type: If docs needed, set a value
Doc Text:
A use-after-free flaw was found in the io_uring in Linux kernel, where a local attacker with a user privilege could cause a denial of service problem on the system.  The issue results from the lack of validating the existence of an object prior to performing operations on the object by not incrementing the file reference counter while in use. The highest threat from this vulnerability is to data integrity, confidentiality and system availability.
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-02-05 08:41:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1873558, 1873559, 1925426    
Bug Blocks: 1858362    

Description Guilherme de Almeida Suckevicz 2020-08-28 12:57:33 UTC
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.

Comment 8 Rohit Keshri 2020-09-02 16:56:07 UTC

Name: Ryota Shiga (Flatt Security)

Comment 9 Rohit Keshri 2020-09-02 16:59:24 UTC

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.

Comment 10 Rohit Keshri 2020-09-02 17:01:40 UTC

The affected code was not introduced into any kernel versions shipped with Red Hat Enterprise Linux making this vulnerable not applicable to these platforms.

Comment 13 msiddiqu 2021-02-05 07:56:29 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1925426]

Comment 14 Product Security DevOps Team 2021-02-05 08:41:44 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


Comment 15 Salvatore Bonaccorso 2021-02-05 22:59:44 UTC

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.


Comment 16 Rohit Keshri 2021-02-08 07:20:10 UTC
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;

	 * 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;

	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

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.

Comment 18 Salvatore Bonaccorso 2021-02-08 09:06:01 UTC
Thank you!

Possible to clarify this as well directly on https://www.openwall.com/lists/oss-security/2021/02/05/7 ?

Comment 19 Justin M. Forbes 2021-02-08 17:27:29 UTC
This issue was fixed for Fedora with the 5.10 kernel rebases.