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.
Security readout for executives and security teams
Plain-English summary
Affected Linux kernels can free a device-memory control-group pool while it is still in use. A later accounting operation can write into freed kernel memory, potentially causing a crash or broader system compromise. Exploitation requires local, low-privileged access and high complexity; public exploitation is not established by the supplied sources.
Executive priority
Treat this as a high-priority kernel maintenance issue on multi-user or locally accessible Linux systems. Prioritize exposed hosts and systems using the affected device-memory accounting path. Emergency incident response is not justified solely by this bundle because active exploitation is unconfirmed and exploitation is rated high complexity.
Technical view
The cgroup/dmem lifecycle incorrectly releases a pool when its memory region is unregistered, despite outstanding caller references. A subsequent uncharge reaches page_counter_uncharge and writes into the freed slab object. The referenced fix adds per-pool reference counting and delays deallocation until the count reaches zero.
Likely exposure
The bundle identifies Linux 6.14, 6.18.10, and 6.19 as affected, but also contains an ambiguous version entry of "0." Exposure is local rather than network-based according to the CVSS vector. Confirm exact distribution kernel ranges and backports with the relevant vendor.
Exploitation context
The CVSS vector rates attack complexity high and requires low local privileges, with no user interaction. The supplied record is not in KEV and provides no evidence of active exploitation or a public exploit. The demonstrated failure involved KASAN and an out-of-tree module, which may not represent every production configuration.
Researcher notes
The evidence clearly supports a pool-lifetime use-after-free and its reference-counting correction. It does not establish a reliable exploitation primitive, affected hardware requirements, configuration prerequisites, or complete fixed release boundaries. The KASAN report shows an eight-byte write during uncharge on a 6.19 release-candidate development kernel.
Mitigation direction
Apply a distribution or vendor kernel update containing the applicable reference-counting fix.
Confirm the update includes one of the referenced stable commits or an equivalent backport.
Consult vendor guidance because the bundle does not name complete fixed-version ranges.
Restrict untrusted local access while updates are pending; no source-backed product-specific workaround is documented.
Validation and detection
Inventory deployed kernel versions and compare them with vendor advisories for CVE-2026-23195.
Verify the running kernel contains the applicable fix through vendor changelogs or commit ancestry.
Determine whether cgroup/dmem memory-region registration and unregistration paths are exercised.
Review kernel diagnostics for use-after-free reports involving page_counter_uncharge or dmem_cgroup_uncharge.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cve · low confidence lookup
CVE-2026-23195 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
0ADP providers
3Source links
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.