CVE-2022-41222

What it actually does

Use-after-free in mm/mremap.c caused by missing rmap lock during PUD move, leaving stale TLB entries that can be dereferenced after the underlying page table structures are freed.

Why it matters to the business

Local attackers on unpatched Linux systems can escalate privileges or crash the kernel, risking data exposure, service outages, and full host compromise; the vulnerability has been public for years with public exploit code available, increasing risk for legacy or embedded deployments.

How an attack unfolds

An attacker with local access crafts a sequence of mremap operations that trigger a PUD move without the rmap lock held; this produces a stale TLB entry referencing freed memory. The use-after-free is then leveraged through careful timing and spraying to achieve arbitrary read/write or code execution within the kernel.

How to fix it

Upgrade the Linux kernel to a version containing commit 97113eb39fa7972722ff490b947d8af023e1f6a2 or later; apply the corresponding security update from the distribution vendor. Reboot after installation. Where immediate patching is impossible, restrict untrusted local code execution via seccomp, containers, or mandatory access controls.

How to confirm the fix worked

Verify kernel version string contains a commit after 97113eb39fa7972722ff490b947d8af023e1f6a2 or matches the fixed package provided by the distribution; run kernel self-tests or memory-management stress tools that exercise mremap paths to confirm absence of the race condition.

Typical attack path

1. Gain local shell or process execution on target system
2. Invoke mremap syscall to move a PUD mapping while racing with other memory operations
3. Trigger use-after-free via stale TLB reference to freed page table entry
4. Spray kernel objects and corrupt freed memory to obtain arbitrary read/write
5. Escalate to root or install persistent implant

How to detect it

Review kernel logs for oops/panic messages referencing mremap or TLB flushing around the time of suspicious process activity; correlate with audit logs showing unusual mremap or memory-mapping syscalls from non-root processes.

What your security team should do

• Prioritize kernel updates on all internet-facing and multi-tenant hosts
• Audit and restrict local user code execution where kernel updates are delayed
• Enable kernel address space layout randomization and page-table isolation features
• Monitor vendor security feeds for backported fixes in older LTS branches