CVE-2022-3910: Linux Kernel Use-After-Free Vulnerability

CVE-2022-3910 Overview

CVE-2022-3910 is a Use After Free vulnerability in the Linux Kernel's io_uring subsystem that enables local privilege escalation. The flaw stems from an improper update of reference count when io_msg_ring is invoked with a fixed file. When this occurs, the kernel incorrectly calls io_fput_file() which improperly decreases the file's reference count. Since fixed files are permanently registered to the ring and should not be released separately, this leads to a Use-After-Free condition that attackers can exploit to escalate privileges on affected systems.

Critical Impact

Local attackers with low privileges can exploit this Use-After-Free vulnerability to achieve full root-level privileges on affected Linux systems, potentially compromising system integrity and confidentiality.

Affected Products

• Linux Kernel versions prior to the fix commit
• Linux Kernel 6.0-rc1 through 6.0-rc5
• Systems using io_uring with fixed file functionality

Discovery Timeline

• November 22, 2022 - CVE CVE-2022-3910 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2022-3910

Vulnerability Analysis

This Use After Free vulnerability exists within the io_msg_ring function of the Linux Kernel's io_uring subsystem. The io_uring interface is a high-performance asynchronous I/O framework that allows applications to efficiently submit and process I/O requests. The vulnerability specifically affects how fixed files—files that are permanently registered with an io_uring ring for repeated use—are handled during message ring operations.

When io_msg_ring processes operations involving fixed files, it erroneously invokes io_fput_file() to release the file reference. However, fixed files maintain a persistent registration with the ring and should never have their reference count decremented through this path. The improper reference count decrement causes the file structure to be freed prematurely while still being referenced by the io_uring ring, creating a classic Use-After-Free condition.

An attacker with local access can manipulate this race condition to corrupt kernel memory structures, ultimately achieving arbitrary code execution with kernel privileges. This enables complete system compromise including the ability to read/write arbitrary kernel memory, disable security mechanisms, and install persistent rootkits.

Root Cause

The root cause is an improper reference count management issue (CWE-416) in the io_uring message ring implementation. The code failed to check whether the file being processed was a fixed file before calling io_put_file(). Fixed files have a different lifecycle than regular files in io_uring—they remain registered throughout the ring's lifetime and should not be individually released. The missing conditional check led to premature deallocation of file structures that were still in active use.

Attack Vector

This is a local attack vector requiring an authenticated attacker with low-level privileges on the target system. The attacker must be able to create io_uring instances and register fixed files, then trigger the vulnerable io_msg_ring code path to cause the reference count underflow. By carefully timing subsequent memory allocations, the attacker can reclaim the freed memory with controlled data, enabling kernel code execution and privilege escalation to root.

// Security patch from io_uring/msg_ring.c - io_uring/msg_ring: check file type before putting
 	req_set_fail(req);
 	io_req_set_res(req, ret, 0);
 	/* put file to avoid an attempt to IOPOLL the req */
-	io_put_file(req->file);
+	if (!(req->flags & REQ_F_FIXED_FILE))
+		io_put_file(req->file);
 	req->file = NULL;
 	return IOU_OK;
}

Source: GitHub Linux Commit

Detection Methods for CVE-2022-3910

Indicators of Compromise

• Unexpected kernel panics or crashes related to io_uring subsystem operations
• Abnormal process privilege changes from unprivileged to root without sudo/su authentication
• Suspicious io_uring system call patterns with fixed file registration followed by msg_ring operations
• Kernel log messages indicating use-after-free or memory corruption in io_uring components

Detection Strategies

• Monitor for processes making intensive io_uring system calls (io_uring_setup, io_uring_enter) especially from non-standard applications
• Deploy kernel address sanitizer (KASAN) in development environments to detect use-after-free conditions
• Implement audit rules to track io_uring syscall usage across the system
• Use SentinelOne's behavioral AI to detect privilege escalation attempts following io_uring activity

Monitoring Recommendations

• Enable kernel auditing for io_uring-related syscalls on critical servers
• Configure alerting for unexpected setuid/setgid changes or capability modifications
• Review process genealogy for suspicious privilege elevation from unprivileged user contexts
• Monitor kernel dmesg output for memory corruption warnings or KASAN reports

How to Mitigate CVE-2022-3910

Immediate Actions Required

• Update the Linux Kernel to a version containing commit fc7222c3a9f56271fba02aabbfbae999042f1679 or later
• Prioritize patching on multi-user systems where local privilege escalation poses the highest risk
• Restrict io_uring access to trusted users via sysctl kernel.io_uring_disabled if available in your kernel version
• Audit systems for signs of previous exploitation before applying patches

Patch Information

The vulnerability has been addressed in the upstream Linux Kernel. The fix adds a conditional check to verify whether the file being processed is a fixed file before calling io_put_file(). If the REQ_F_FIXED_FILE flag is set, the file release is skipped, preventing the improper reference count decrement. Organizations should update to kernel versions that include commit fc7222c3a9f56271fba02aabbfbae999042f1679 or apply patches from their distribution vendor.

Workarounds

• Disable io_uring system-wide using sysctl: kernel.io_uring_disabled=2 (requires kernel 5.19.4+ or 5.18.18+)
• Restrict io_uring access using seccomp filters to block io_uring_setup and io_uring_enter syscalls
• Limit local user access on affected systems until patches can be applied
• Use container isolation with seccomp profiles that block io_uring syscalls for untrusted workloads

# Configuration example - Disable io_uring system-wide (requires kernel 5.19.4+ or 5.18.18+)
echo "kernel.io_uring_disabled = 2" >> /etc/sysctl.d/99-disable-io_uring.conf
sysctl -p /etc/sysctl.d/99-disable-io_uring.conf

# Verify io_uring is disabled
sysctl kernel.io_uring_disabled