Memory Leak Affecting kernel-64k-modules package, versions <0:5.14.0-284.11.1.el9_2


Severity

Recommended
high

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.05% (17th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Memory Leak vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-RHEL9-KERNEL64KMODULES-10048800
  • published6 May 2025
  • disclosed26 Feb 2025

Introduced: 26 Feb 2025

CVE-2022-49080  (opens in a new tab)
CWE-401  (opens in a new tab)

How to fix?

Upgrade RHEL:9 kernel-64k-modules to version 0:5.14.0-284.11.1.el9_2 or higher.
This issue was patched in RHSA-2023:2458.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-64k-modules package and not the kernel-64k-modules package as distributed by RHEL. See How to fix? for RHEL:9 relevant fixed versions and status.

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

mm/mempolicy: fix mpol_new leak in shared_policy_replace

If mpol_new is allocated but not used in restart loop, mpol_new will be freed via mpol_put before returning to the caller. But refcnt is not initialized yet, so mpol_put could not do the right things and might leak the unused mpol_new. This would happen if mempolicy was updated on the shared shmem file while the sp->lock has been dropped during the memory allocation.

This issue could be triggered easily with the below code snippet if there are many processes doing the below work at the same time:

shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); }

CVSS Base Scores

version 3.1