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

CVE-2022-41222 Overview

CVE-2022-41222 is a use-after-free vulnerability in the Linux kernel memory management subsystem. The flaw resides in mm/mremap.c and affects Linux kernel versions prior to 5.13.3. The root issue is a stale Translation Lookaside Buffer (TLB) entry caused by a missing reverse mapping (rmap) lock during a Page Upper Directory (PUD) move operation. A local authenticated attacker can leverage the race condition to access freed memory, potentially leading to privilege escalation on affected systems. The vulnerability was reported through Google Project Zero and patched upstream in Linux 5.13.3.

Critical Impact
Local attackers with low privileges can exploit a use-after-free in kernel memory remapping to compromise confidentiality, integrity, and availability of the host.

Affected Products

Linux kernel versions prior to 5.13.3
Debian Linux 10 and supported LTS releases
Canonical Ubuntu Linux 18.04 LTS, 20.04 LTS, and 22.04 LTS
NetApp HCI Baseboard Management Controller (H300S, H410C, H410S, H500S, H700S)

Discovery Timeline

2022-09-21 - CVE-2022-41222 published to the National Vulnerability Database (NVD)
2025-05-28 - Last updated in NVD database

Technical Details for CVE-2022-41222

Vulnerability Analysis

The vulnerability is a use-after-free condition [CWE-416] in the Linux kernel's mremap() implementation. The mremap() system call allows userspace processes to expand, shrink, or relocate virtual memory regions. During a relocation, the kernel must move page table entries from the old virtual address range to the new range while keeping the reverse mapping consistent with anonymous and file-backed pages.

When the move operation crosses a Page Upper Directory boundary, the kernel handles the relocation at the PUD level by directly moving the PUD entry instead of iterating individual pages. Before the fix, this PUD move path did not acquire the rmap lock that synchronizes page table changes with reverse-mapping walkers. As a result, another CPU could observe stale TLB entries pointing to memory that had already been freed and reused.

Root Cause

The defect is a missing lock acquisition in the fast PUD move path within mm/mremap.c. The rmap lock serializes page table modifications against rmap walkers used by reclaim and migration. Without holding this lock, the kernel can free physical pages while another core still resolves virtual addresses through cached TLB entries, producing a window where freed memory is accessible through stale mappings.

Attack Vector

Exploitation requires local access and the ability to invoke mremap() on attacker-controlled mappings. The attacker races multiple threads to trigger the unsynchronized PUD move while another thread or the kernel reclaims the affected pages. Successful exploitation grants read or write access to freed kernel-managed memory, which can be leveraged for privilege escalation. The Google Project Zero report tracked as Issue #2347 documents the race condition in detail, and a working proof-of-concept was published on Packet Storm.

No verified exploitation code is reproduced here. Refer to the Project Zero Issue #2347 and the upstream kernel commit 97113eb39fa7972 for technical details on the race window and the corrective locking.

Detection Methods for CVE-2022-41222

Indicators of Compromise

Unexpected kernel oops, general protection faults, or panics referencing mremap, move_page_tables, or move_normal_pud in dmesg or /var/log/kern.log.
Local processes invoking mremap() with MREMAP_FIXED against large mappings aligned to PUD boundaries (typically 1 GiB on x86_64) in a tight multi-threaded loop.
Unprivileged processes that suddenly gain root capabilities without a corresponding setuid execution event.

Detection Strategies

Inventory all Linux hosts and compare running kernel versions against 5.13.3 and distribution-specific patched builds from Debian, Ubuntu, and NetApp advisories.
Audit eBPF and tracing telemetry for high-frequency mremap syscalls originating from non-system processes.
Correlate kernel crash signatures with subsequent privilege changes on the same host to identify post-exploitation activity.

Monitoring Recommendations

Enable kernel crash collection (kdump) and ship crash reports to a centralized log platform for retrospective analysis.
Monitor auditd for unusual execve events spawned from processes that previously called mremap() at high rates.
Alert on new UID 0 sessions originating from non-administrative parent processes.

How to Mitigate CVE-2022-41222

Immediate Actions Required

Upgrade Linux kernels to 5.13.3 or later, or apply the vendor backport from Debian, Ubuntu, or NetApp covering CVE-2022-41222.
Reboot affected hosts after package upgrades to ensure the patched kernel image is loaded, or apply a kernel live patch where supported.
Restrict shell and container execution on multi-tenant hosts until patching is verified.

Patch Information

The upstream fix is included in Linux 5.13.3 via kernel commit 97113eb39fa7972, which adds the missing rmap lock around the PUD move path. Distribution updates are available in the Linux Kernel ChangeLog 5.13.3, the Debian LTS Announcement November 2022, the Ubuntu Kernel Live Patch Security Notice LNS-0091-1, and the NetApp Security Advisory NTAP-20230214-0008.

Workarounds

Reduce attack surface by limiting local logon and disabling untrusted code execution on sensitive hosts until kernel updates are deployed.
Constrain container workloads with seccomp profiles that block or restrict the mremap syscall where feasible.
Apply kernel live patches from vendors such as Canonical Livepatch to mitigate the use-after-free without an immediate reboot.

bash

# Verify the running kernel is patched (Linux 5.13.3 or later, or vendor backport)
uname -r

# Debian/Ubuntu: install the latest kernel package and reboot
sudo apt update && sudo apt upgrade linux-image-$(uname -r | sed 's/-.*//') -y
sudo reboot

# Restrict mremap via a seccomp profile snippet (illustrative)
# Add to a container runtime seccomp policy:
#   { "names": ["mremap"], "action": "SCMP_ACT_ERRNO" }