CVE-2022-49080
published 2025-02-26CVE-2022-49080: 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…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.31%
22.9th percentile
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);
}
Affected
25 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.17.3-1 (bookworm) | linux 5.17.3-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 42288fe366c4f1ce7522bc9f27d0bc2a81c55264 < 8510c2346d9e47a72b7f018a36ef0c39483e53d6 | 8510c2346d9e47a72b7f018a36ef0c39483e53d6 |
| linux | linux | >= 42288fe366c4f1ce7522bc9f27d0bc2a81c55264 < 5e16dc5378abd749a836daa9ee4ab2c8d2668999 | 5e16dc5378abd749a836daa9ee4ab2c8d2668999 |
| linux | linux | >= 42288fe366c4f1ce7522bc9f27d0bc2a81c55264 < 39a32f3c06f6d68a530bf9612afa19f50f12e93d | 39a32f3c06f6d68a530bf9612afa19f50f12e93d |
| linux | linux | >= 42288fe366c4f1ce7522bc9f27d0bc2a81c55264 < 25f506273b6ae806fd46bfcb6fdaa5b9ec81a05b | 25f506273b6ae806fd46bfcb6fdaa5b9ec81a05b |
| linux | linux | >= 42288fe366c4f1ce7522bc9f27d0bc2a81c55264 < f7e183b0a7136b6dc9c7b9b2a85a608a8feba894 | f7e183b0a7136b6dc9c7b9b2a85a608a8feba894 |
| linux | linux | >= 42288fe366c4f1ce7522bc9f27d0bc2a81c55264 < 198932a14aeb19a15cf19e51e151d023bc4cd648 | 198932a14aeb19a15cf19e51e151d023bc4cd648 |
| linux | linux | >= 42288fe366c4f1ce7522bc9f27d0bc2a81c55264 < 6e00309ac716fa8225f0cbde2cd9c24f0e74ee21 | 6e00309ac716fa8225f0cbde2cd9c24f0e74ee21 |
| linux | linux | >= 42288fe366c4f1ce7522bc9f27d0bc2a81c55264 < fe39ac59dbbf893b73b24e3184161d0bd06d6651 | fe39ac59dbbf893b73b24e3184161d0bd06d6651 |
| linux | linux | >= 42288fe366c4f1ce7522bc9f27d0bc2a81c55264 < 4ad099559b00ac01c3726e5c95dc3108ef47d03e | 4ad099559b00ac01c3726e5c95dc3108ef47d03e |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.113-1 | 5.10.113-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
| linux | linux_kernel | >= 0 < 5.17.3-1 | 5.17.3-1 |
| linux | linux_kernel | >= 3.8.1 < 4.9.311 | 4.9.311 |
| linux | linux_kernel | >= 4.10 < 4.14.276 | 4.14.276 |
| linux | linux_kernel | >= 4.15 < 4.19.238 | 4.19.238 |
| linux | linux_kernel | >= 4.20 < 5.4.189 | 5.4.189 |
| linux | linux_kernel | >= 5.11 < 5.15.34 | 5.15.34 |
| linux | linux_kernel | >= 5.16 < 5.16.20 | 5.16.20 |
| linux | linux_kernel | >= 5.17 < 5.17.3 | 5.17.3 |
| linux | linux_kernel | >= 5.5 < 5.10.111 | 5.10.111 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: mm/mempolicy: fix mpol_new leak in shared_policy_replace
vendor_redhat·2025-02-26·CVSS 5.5
CVE-2022-49080 [MEDIUM] CWE-401 kernel: mm/mempolicy: fix mpol_new leak in shared_policy_replace
kernel: mm/mempolicy: fix mpol_new leak in shared_policy_replace
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 {
Debian
CVE-2022-49080: linux - In the Linux kernel, the following vulnerability has been resolved: mm/mempolic...
vendor_debian·2022·CVSS 5.5
CVE-2022-49080 [MEDIUM] CVE-2022-49080: linux - In the Linux kernel, the following vulnerability has been resolved: mm/mempolic...
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(
GHSA
GHSA-rx6x-4frg-6jxm: In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix mpol_new leak in shared_policy_replace
If mpol_new is allocate
ghsa_unreviewed·2025-09-23
CVE-2022-49080 [MEDIUM] CWE-401 GHSA-rx6x-4frg-6jxm: In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix mpol_new leak in shared_policy_replace
If mpol_new is allocate
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);
mb
OSV
CVE-2022-49080: 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
osv·2025-02-26·CVSS 5.5
CVE-2022-49080 [MEDIUM] CVE-2022-49080: 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
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(
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/198932a14aeb19a15cf19e51e151d023bc4cd648https://git.kernel.org/stable/c/25f506273b6ae806fd46bfcb6fdaa5b9ec81a05bhttps://git.kernel.org/stable/c/39a32f3c06f6d68a530bf9612afa19f50f12e93dhttps://git.kernel.org/stable/c/4ad099559b00ac01c3726e5c95dc3108ef47d03ehttps://git.kernel.org/stable/c/5e16dc5378abd749a836daa9ee4ab2c8d2668999https://git.kernel.org/stable/c/6e00309ac716fa8225f0cbde2cd9c24f0e74ee21https://git.kernel.org/stable/c/8510c2346d9e47a72b7f018a36ef0c39483e53d6https://git.kernel.org/stable/c/f7e183b0a7136b6dc9c7b9b2a85a608a8feba894https://git.kernel.org/stable/c/fe39ac59dbbf893b73b24e3184161d0bd06d6651
2025-02-26
Published