CVE-2026-23195 in Linux
Summary
by MITRE • 02/14/2026
In the Linux kernel, the following vulnerability has been resolved:
cgroup/dmem: avoid pool UAF
An UAF issue was observed:
BUG: KASAN: slab-use-after-free in page_counter_uncharge+0x65/0x150 Write of size 8 at addr ffff888106715440 by task insmod/527
CPU: 4 UID: 0 PID: 527 Comm: insmod 6.19.0-rc7-next-20260129+ #11 Tainted: [O]=OOT_MODULE
Call Trace: <TASK> dump_stack_lvl+0x82/0xd0 kasan_report+0xca/0x100 kasan_check_range+0x39/0x1c0 page_counter_uncharge+0x65/0x150 dmem_cgroup_uncharge+0x1f/0x260
Allocated by task 527:
Freed by task 0:
The buggy address belongs to the object at ffff888106715400 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 64 bytes inside of freed 512-byte region [ffff888106715400, ffff888106715600)
The buggy address belongs to the physical page:
Memory state around the buggy address: ffff888106715300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888106715380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888106715400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888106715480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888106715500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
The issue occurs because a pool can still be held by a caller after its associated memory region is unregistered. The current implementation frees the pool even if users still hold references to it (e.g., before uncharge operations complete).
This patch adds a reference counter to each pool, ensuring that a pool is only freed when its reference count drops to zero.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 05/05/2026
The vulnerability described in CVE-2026-23195 represents a critical use-after-free condition within the Linux kernel's cgroup memory management subsystem, specifically affecting the dmem (dynamic memory) cgroup implementation. This flaw exists in the interaction between memory pool management and reference counting mechanisms, creating a scenario where memory objects can be accessed after being freed, potentially leading to system instability or privilege escalation. The issue manifests during kernel module loading operations through the insmod command, indicating that the vulnerability can be triggered by legitimate system administration activities, making it particularly concerning for production environments.
The technical root cause of this vulnerability lies in the improper handling of memory pool references within the cgroup subsystem. When a memory region is unregistered, the associated pool structure is freed even though callers may still hold references to it, particularly during ongoing uncharge operations. This creates a race condition where memory that has been freed according to the kernel's allocation tracking but is still actively referenced by ongoing operations becomes accessible for reuse. The KASAN (Kernel Address Sanitizer) detection reveals that the freed memory region at address ffff888106715400 was accessed through the page_counter_uncharge function, which attempts to write an 8-byte value to memory that had already been freed. This specific memory access pattern represents a classic use-after-free scenario where the memory layout shows clear evidence of deallocated memory being reused, with the bytes at the freed address containing the expected deallocation pattern of fb fb fb fb...
The operational impact of this vulnerability extends beyond simple system crashes, potentially enabling privilege escalation attacks by allowing attackers to manipulate freed memory objects to execute arbitrary code. The vulnerability affects the cgroup memory management system which is fundamental to Linux containerization and resource isolation, making it particularly dangerous in virtualized environments where multiple tenants share the same kernel. Attackers could potentially exploit this condition by carefully crafting memory allocation patterns that would cause the kernel to free memory while still in use, then manipulating the freed memory to achieve code execution. This represents a serious security risk that could compromise the integrity of the entire system, especially when combined with other kernel vulnerabilities or when executed in environments where unprivileged users have access to kernel module loading capabilities.
The fix implemented addresses this vulnerability by introducing a reference counting mechanism for memory pools, ensuring that pools are only freed when all references to them have been properly released. This approach aligns with established security practices for memory management in kernel space, where proper reference counting prevents the premature deallocation of objects that may still be in use. The solution follows the principle of defensive programming by adding explicit lifecycle management to the memory pool objects, preventing the scenario where a pool's memory is freed while still referenced by active operations. This patch demonstrates adherence to security standards such as those outlined in CWE-416, which specifically addresses use-after-free vulnerabilities, and provides a robust mitigation strategy that prevents the conditions leading to memory corruption. The implementation requires careful coordination between the cgroup subsystem and memory management components, ensuring that all callers properly increment and decrement reference counts during their operations, thereby maintaining the integrity of the memory pool management system throughout the entire lifecycle of memory resources.