CVE-2024-26832
published 2024-04-17CVE-2024-26832: In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry()…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.22%
13.1th percentile
In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: fix missing folio cleanup in writeback race path
In zswap_writeback_entry(), after we get a folio from
__read_swap_cache_async(), we grab the tree lock again to check that the
swap entry was not invalidated and recycled. If it was, we delete the
folio we just added to the swap cache and exit.
However, __read_swap_cache_async() returns the folio locked when it is
newly allocated, which is always true for this path, and the folio is
ref'd. Make sure to unlock and put the folio before returning.
This was discovered by code inspection, probably because this path handles
a race condition that should not happen often, and the bug would not crash
the system, it will only strand the folio indefinitely.
Affected
17 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.82-1 (bookworm) | linux 6.1.82-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | — | — |
| linux | linux | >= 04fc7816089c5a32c29a04ec94b998e219dfb946 < 6156277d1b26cb3fdb6fcbf0686ab78268571644 | 6156277d1b26cb3fdb6fcbf0686ab78268571644 |
| linux | linux | >= 04fc7816089c5a32c29a04ec94b998e219dfb946 < e2891c763aa2cff74dd6b5e978411ccf0cf94abe | e2891c763aa2cff74dd6b5e978411ccf0cf94abe |
| linux | linux | >= 04fc7816089c5a32c29a04ec94b998e219dfb946 < e3b63e966cac0bf78aaa1efede1827a252815a1d | e3b63e966cac0bf78aaa1efede1827a252815a1d |
| linux | linux | >= 2cab13f500a6333bd2b853783ac76be9e4956f8a < 14f1992430ef9e647b02aa8ca12c5bcb9a1dffea | 14f1992430ef9e647b02aa8ca12c5bcb9a1dffea |
| linux | linux | >= 6.1.30 < 6.1.80 | 6.1.80 |
| linux | linux | >= 6.3.4 < 6.4 | 6.4 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.82-1 | 6.1.82-1 |
| linux | linux_kernel | >= 0 < 6.7.7-1 | 6.7.7-1 |
| linux | linux_kernel | >= 0 < 6.7.7-1 | 6.7.7-1 |
| linux | linux_kernel | >= 6.1.30 < 6.1.80 | 6.1.80 |
| linux | linux_kernel | >= 6.4 < 6.6.19 | 6.6.19 |
| linux | linux_kernel | >= 6.7 < 6.7.7 | 6.7.7 |
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: zswap: fix missing folio cleanup in writeback race path
vendor_redhat·2024-04-17·CVSS 5.5
CVE-2024-26832 [MEDIUM] CWE-362 kernel: mm: zswap: fix missing folio cleanup in writeback race path
kernel: mm: zswap: fix missing folio cleanup in writeback race path
In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: fix missing folio cleanup in writeback race path
In zswap_writeback_entry(), after we get a folio from
__read_swap_cache_async(), we grab the tree lock again to check that the
swap entry was not invalidated and recycled. If it was, we delete the
folio we just added to the swap cache and exit.
However, __read_swap_cache_async() returns the folio locked when it is
newly allocated, which is always true for this path, and the folio is
ref'd. Make sure to unlock and put the folio before returning.
This was discovered by code inspection, probably because this path handles
a race condition that should not happen often, and the bug would not crash
the
Debian
CVE-2024-26832: linux - In the Linux kernel, the following vulnerability has been resolved: mm: zswap: ...
vendor_debian·2024·CVSS 5.5
CVE-2024-26832 [MEDIUM] CVE-2024-26832: linux - In the Linux kernel, the following vulnerability has been resolved: mm: zswap: ...
In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.
Scope: local
book
GHSA
GHSA-fpqf-cxvg-rf89: In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: fix missing folio cleanup in writeback race path
In zswap_writeback_e
ghsa_unreviewed·2024-04-17
CVE-2024-26832 [MEDIUM] CWE-459 GHSA-fpqf-cxvg-rf89: In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: fix missing folio cleanup in writeback race path
In zswap_writeback_e
In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: fix missing folio cleanup in writeback race path
In zswap_writeback_entry(), after we get a folio from
__read_swap_cache_async(), we grab the tree lock again to check that the
swap entry was not invalidated and recycled. If it was, we delete the
folio we just added to the swap cache and exit.
However, __read_swap_cache_async() returns the folio locked when it is
newly allocated, which is always true for this path, and the folio is
ref'd. Make sure to unlock and put the folio before returning.
This was discovered by code inspection, probably because this path handles
a race condition that should not happen often, and the bug would not crash
the system, it will only strand the folio indefinitely.
OSV
CVE-2024-26832: In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_ent
osv·2024-04-17·CVSS 5.5
CVE-2024-26832 [MEDIUM] CVE-2024-26832: In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_ent
In the Linux kernel, the following vulnerability has been resolved: mm: zswap: fix missing folio cleanup in writeback race path In zswap_writeback_entry(), after we get a folio from __read_swap_cache_async(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit. However, __read_swap_cache_async() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning. This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/14f1992430ef9e647b02aa8ca12c5bcb9a1dffeahttps://git.kernel.org/stable/c/6156277d1b26cb3fdb6fcbf0686ab78268571644https://git.kernel.org/stable/c/e2891c763aa2cff74dd6b5e978411ccf0cf94abehttps://git.kernel.org/stable/c/e3b63e966cac0bf78aaa1efede1827a252815a1dhttps://git.kernel.org/stable/c/14f1992430ef9e647b02aa8ca12c5bcb9a1dffeahttps://git.kernel.org/stable/c/6156277d1b26cb3fdb6fcbf0686ab78268571644https://git.kernel.org/stable/c/e2891c763aa2cff74dd6b5e978411ccf0cf94abehttps://git.kernel.org/stable/c/e3b63e966cac0bf78aaa1efede1827a252815a1d
2024-04-17
Published