Bug 2482029 (CVE-2026-46042)

Summary: CVE-2026-46042 kernel: mm/mempolicy: fix memory leaks in weighted_interleave_auto_store()
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the Linux kernel's memory management policy (mm/mempolicy) component, specifically within the `weighted_interleave_auto_store()` function. This vulnerability allows a local user to repeatedly trigger memory leaks by writing specific values. The continuous memory allocation without proper deallocation can lead to resource exhaustion, potentially resulting in a Denial of Service (DoS) condition for the system.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-05-27 15:07:50 UTC 
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.com>
Comment 1 Keith Grant 2026-05-27 19:37:35 UTC 
Upstream advisory:
https://lore.kernel.org/linux-cve-announce/2026052751-CVE-2026-46042-94e1@gregkh/T