CVE-2026-46042: mm/mempolicy: fix memory leaks in weighted_interleave_auto_store()

Published May 27, 2026
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

mm/mempolicy: fix memory leaks in weightedinterleaveautostore()

weightedinterleaveautostore() fetches oldwistate 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 newwistate.

2. When a user writes "true", oldwistate stays NULL because the fetch is skipped entirely. The old state is then overwritten by rcuassignpointer() but never freed, since the cleanup path is gated on oldwistate being non-NULL. A user can trigger this repeatedly by writing "1" in a loop.

Fix both leaks by moving the oldwistate 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>

Affected Software

3 affected components
Linux Linux kernel
Linux Linux kernel>=6.16<6.18.27
Linux Linux kernel>=6.19<7.0.4

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Operational

    Apply the upstream code fix that moves the old_wi_state fetch before the input check in mm/mempolicy:weighted_interleave_auto_store() to eliminate the two memory leaks (as described in the remedy text).

Event History

May 27, 2026
CVE Published
via MITRE·12:56 PM
Data Sourced
via MITRE·12:56 PM
Description
Data Sourced
via NVD·02:17 PM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What access does an attacker need to trigger the issue?

Systems are exposed when a local user with the required ability to write the weighted interleave auto setting can repeatedly change that setting. The CVSS vector identifies local access and low privileges as required; no user interaction is required.

2

How could this be abused to affect availability?

Repeated writes of "1" can leak the prior weighted interleave state on each write. Writing "false" can also leak a newly allocated state when the current mode is already manual.

3

What mitigation is available before updating the kernel?

If patching cannot be applied immediately, restrict access to the interface that controls weighted_interleave_auto and prevent untrusted local users or workloads from repeatedly writing "1" or toggling the setting. This reduces the ability to accumulate leaked memory.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203