CVE-2023-23586

What it actually does

The flaw is a use-after-free in the io_uring subsystem where timens_install does not account for io_uring worker threads when checking single-threaded status, allowing a time namespace vvar page to be inserted, freed on namespace destruction, and subsequently read by a user process to leak kernel memory contents.

Why it matters to the business

Local attackers on affected Linux systems can read sensitive kernel memory, increasing risk of privilege escalation or further exploitation on high-value servers; prevalence across the Linux ecosystem makes broad kernel upgrades operationally urgent though EPSS remains low.

How an attack unfolds

A local attacker with user privileges crafts io_uring operations to trigger page-fault insertion of a time-namespace vvar page, destroys the namespace to free the page while it remains mapped, then reads the now-reused memory region to exfiltrate kernel data; no remote vector or public exploit code is known.

How to fix it

Upgrade the Linux kernel past version 5.10.161 or apply commit 1a9148dfd8e03835dc7617cee696dd18c0000e99 (or the referenced stable commit 788d0824269bef539fe31a785b1517882eafed93) in the io_uring and time-namespace code paths; rebuild and reboot all affected systems.

How to confirm the fix worked

Verify running kernel version is at or above the fixed release; confirm the patch commit is present in the source tree; test that io_uring time-namespace operations no longer permit cross-page reads after namespace destruction.

Typical attack path

1. Obtain local unprivileged shell on target Linux host
2. Use io_uring syscalls to manipulate time namespace and trigger page fault mapping
3. Destroy the time namespace to free the vvar page without removing the mapping
4. Allocate new kernel memory and read the stale mapping to leak contents

How to detect it

Review kernel audit logs and io_uring tracepoints for unusual time-namespace creation/destruction sequences paired with page-fault activity; look for processes using io_uring that also manipulate CLONE_NEWUSER or timens; no public exploit artifacts are known.

What your security team should do

• Prioritize kernel upgrades on all internet-facing and multi-tenant Linux hosts within the next maintenance window
• Monitor EPSS and exploit maturity; raise priority if either increases
• Restrict untrusted local users from io_uring via seccomp or kernel config where feasible until patched