CVE-2026-46042: mm/mempolicy: fix memory leaks in weighted_interleave_auto_store()
In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix memory leaks in weighted_interleave_auto_store()
weighted_interleave_auto_store() fetches old_wi_state inside the if
(!input) block only. This causes two memory leaks:
1. When a user writes "false" and the current mode is already manual,
the function returns early without freeing the freshly allocated
new_wi_state.
2. When a user writes "true", old_wi_state stays NULL because the
fetch is skipped entirely. The old state is then overwritten by
rcu_assign_pointer() but never freed, since the cleanup path is
gated on old_wi_state being non-NULL. A user can trigger this
repeatedly by writing "1" in a loop.
Fix both leaks by moving the old_wi_state fetch before the input check,
making it unconditional. This also allows a unified early return for both
"true" and "false" when the requested mode matches the current mode.
Reviewed by: Donet Tom <donettom@linux.ibm.com>
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue is a memory leak in memory policy handling. A local user changing the weighted interleave mode can cause old or newly allocated state to remain unfreed. The sources describe a repeatable leak but do not provide CVSS, impact rating, or active exploitation evidence.
Executive priority
Treat this as a patch-tracking item, not an emergency, unless affected kernels run on shared or hostile multi-user systems. The available evidence supports a local memory leak risk, but not active exploitation or remote compromise.
Technical view
The bug is in weighted_interleave_auto_store(). old_wi_state was fetched only in the !input path, so some early returns leaked new_wi_state and true-mode updates overwrote the old RCU pointer without freeing it. Linux stable commits fix this by fetching old_wi_state unconditionally and unifying same-mode returns.
Likely exposure
Exposure appears limited to Linux systems running affected kernel versions containing the vulnerable mm/mempolicy code. The source bundle lists Linux as the affected product but does not clarify distributions, configurations, privileges required, or exact reachable interfaces.
Exploitation context
CISA KEV is false and the provided sources do not claim active exploitation. The CVE description says a user can trigger the leak repeatedly by changing the setting, suggesting local misuse could create resource pressure. No remote attack path is described.
Researcher notes
Version data in the bundle is incomplete and unusual, with no CVSS or CWE. The clearest evidence is the Linux stable fix rationale. Avoid over-scoping beyond Linux kernel mm/mempolicy until vendor advisories map affected distribution kernels.
Mitigation direction
Check Linux distribution advisories for kernels containing the referenced stable fixes.
Prioritize patching multi-user Linux systems where local users or workloads are less trusted.
Track whether deployed kernels include the three referenced Linux stable commits.
If patching is delayed, monitor memory pressure on affected hosts.
Validation and detection
Inventory Linux kernel versions across production and shared compute systems.
Compare deployed kernel build provenance against vendor advisories and stable commit inclusion.
Review monitoring for unusual kernel memory growth on candidate affected systems.
Document any systems requiring vendor confirmation because version mapping is unclear.
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-46042 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.
0CVSS vectors
3Timeline events
0ADP providers
4Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
May 27, 2026, 12:56 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.