CVE-2026-93216 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
mm/page_owner: use memcg_data snapshot to avoid TOCTOU in print_page_owner_memcg()
print_page_owner_memcg() reads page->memcg_data via READ_ONCE() at the start to guard against tail pages and NULL data. However, it later re-reads page->memcg_data locklessly in two places:
1: page_memcg_check(page)
2: PageMemcgKmem(page) (via folio_memcg_kmem(), which includes VM_BUG_ON assertions for tail pages and MEMCG_DATA_OBJEXTS)
If the page is concurrently freed and reallocated as a THP tail page or slab page between these calls, the VM_BUG_ON assertions can trigger on CONFIG_DEBUG_VM=y builds, crashing the kernel.
Fix both TOCTOU issues by using the memcg_data snapshot throughout.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel vulnerability identified in the memory management subsystem involves a time-of-check-to-time-of-use race condition within the print_page_owner_memcg function. This issue arises from an inconsistent handling of page metadata, specifically the memcg_data field which tracks memory control group associations for pages. The root cause lies in the function's attempt to balance safety checks against concurrent modifications with efficient lockless access patterns. Initially, the code correctly employs a READ_ONCE macro to capture a snapshot of page->memcg_data at the beginning of execution. This initial read is designed to guard against tail pages and NULL data pointers that might appear if the underlying memory structure changes during processing. However, this protective measure is undermined by subsequent operations that bypass the captured snapshot in favor of fresh lockless reads from the live kernel structures.
The technical flaw manifests when two specific macros are invoked after the initial snapshot has been taken but before the function completes its analysis. The first instance involves page_memcg_check which performs a direct read of the current state of page->memcg_data. The second instance occurs through PageMemcgKmem, which internally calls folio_memcg_kmem and includes VM_BUG_ON assertions to validate tail pages and MEMCG_DATA_OBJEXTS states. These subsequent reads do not utilize the previously captured snapshot but instead access the memory location directly from the page structure in real-time. This creates a window of vulnerability where the state observed at the start no longer matches the state accessed later, violating the consistency required for safe debugging operations.
The operational impact of this race condition is most severe on kernels compiled with CONFIG_DEBUG_VM enabled. In such configurations, the VM_BUG_ON assertions within folio_memcg_kmem are active and will trigger if they detect an inconsistent or unexpected page type during execution. If a memory page is concurrently freed by one thread and reallocated as either a Transparent Huge Page tail page or a slab object in another thread between the initial snapshot and the subsequent checks, the assertion logic interprets this state transition as a critical error. This results in a kernel panic or crash, effectively causing a denial of service for systems relying on these debugging features. While the issue primarily affects debug builds, it highlights a fundamental inconsistency in how memory metadata is accessed during diagnostic routines, which could potentially lead to undefined behavior even if assertions are disabled depending on compiler optimizations and specific hardware architectures.
From a security taxonomy perspective, this vulnerability aligns with CWE-367, Time-of-check Time-of-use (TOCTOU) race condition, as the system checks one state of an object but acts upon another due to concurrent modification. It also relates to CWE-824, Access of Memory Location After Free, in scenarios where the page structure might be partially deallocated or repurposed before all references are resolved. In terms of MITRE ATT&CK techniques, this represents a potential vector for local privilege escalation if an attacker can trigger specific memory allocation patterns to force the race condition and crash critical kernel services, thereby disrupting system availability. Although primarily a stability issue in debug builds, such races can sometimes be leveraged to obscure malicious activity or cause resource exhaustion attacks against production systems that might have similar but less strict validation logic.
To mitigate this vulnerability, developers must ensure that all accesses to page metadata within the diagnostic function rely on the initial snapshot rather than re-reading from memory. By consistently using the memcg_data variable captured at the start of print_page_owner_memcg(), the code eliminates the race window where concurrent frees and reallocations could cause state mismatches. This approach ensures that the debugging output reflects a consistent view of the page's history without being corrupted by live changes occurring during the inspection process. For system administrators, applying kernel updates that include this fix is essential to maintain stability on systems running with verbose memory debugging enabled. In production environments where debug flags are disabled, while the immediate crash risk is removed, maintaining up-to-date kernels remains critical as similar patterns in other subsystems could present more severe security implications if not properly synchronized.