CVE-2024-26630
published 2024-03-13CVE-2024-26630: In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix folio read-after-free in cache walk In cachestat, we access the folio…
PriorityP429high7.1CVSS 3.1
AVLACLPRLUINSUCHINAH
EPSS
0.30%
22.5th percentile
In the Linux kernel, the following vulnerability has been resolved:
mm: cachestat: fix folio read-after-free in cache walk
In cachestat, we access the folio from the page cache's xarray to compute
its page offset, and check for its dirty and writeback flags. However, we
do not hold a reference to the folio before performing these actions,
which means the folio can concurrently be released and reused as another
folio/page/slab.
Get around this altogether by just using xarray's existing machinery for
the folio page offsets and dirty/writeback states.
This changes behavior for tmpfs files to now always report zeroes in their
dirty and writeback counters. This is okay as tmpfs doesn't follow
conventional writeback cache behavior: its pages get "cleaned" during
swapout, after which they're no longer resident etc.
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.7.9-1 (forky) | linux 6.7.9-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= cf264e1329fb0307e044f7675849f9f38b44c11a < ba60fdf75e89ea762bb617be578dc47f27655117 | ba60fdf75e89ea762bb617be578dc47f27655117 |
| linux | linux | >= cf264e1329fb0307e044f7675849f9f38b44c11a < fe7e008e0ce728252e4ec652cceebcc62211657c | fe7e008e0ce728252e4ec652cceebcc62211657c |
| linux | linux | >= cf264e1329fb0307e044f7675849f9f38b44c11a < 3a75cb05d53f4a6823a32deb078de1366954a804 | 3a75cb05d53f4a6823a32deb078de1366954a804 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.7.9-1 | 6.7.9-1 |
| linux | linux_kernel | >= 0 < 6.7.9-1 | 6.7.9-1 |
| linux | linux_kernel | >= 6.5 < 6.6.21 | 6.6.21 |
| linux | linux_kernel | >= 6.7 < 6.7.9 | 6.7.9 |
CVSS provenance
nvdv3.17.1HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
osv7.1HIGH
vendor_debian7.1LOW
vendor_redhat7.1HIGH
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.
GHSA
GHSA-8h7v-x635-x447: In the Linux kernel, the following vulnerability has been resolved:
mm: cachestat: fix folio read-after-free in cache walk
In cachestat, we access t
ghsa_unreviewed·2024-03-13
CVE-2024-26630 [HIGH] CWE-416 GHSA-8h7v-x635-x447: In the Linux kernel, the following vulnerability has been resolved:
mm: cachestat: fix folio read-after-free in cache walk
In cachestat, we access t
In the Linux kernel, the following vulnerability has been resolved:
mm: cachestat: fix folio read-after-free in cache walk
In cachestat, we access the folio from the page cache's xarray to compute
its page offset, and check for its dirty and writeback flags. However, we
do not hold a reference to the folio before performing these actions,
which means the folio can concurrently be released and reused as another
folio/page/slab.
Get around this altogether by just using xarray's existing machinery for
the folio page offsets and dirty/writeback states.
This changes behavior for tmpfs files to now always report zeroes in their
dirty and writeback counters. This is okay as tmpfs doesn't follow
conventional writeback cache behavior: its pages get "cleaned" during
swapout, after which they're
OSV
CVE-2024-26630: In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix folio read-after-free in cache walk In cachestat, we access the
osv·2024-03-13·CVSS 7.1
CVE-2024-26630 [HIGH] CVE-2024-26630: In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix folio read-after-free in cache walk In cachestat, we access the
In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix folio read-after-free in cache walk In cachestat, we access the folio from the page cache's xarray to compute its page offset, and check for its dirty and writeback flags. However, we do not hold a reference to the folio before performing these actions, which means the folio can concurrently be released and reused as another folio/page/slab. Get around this altogether by just using xarray's existing machinery for the folio page offsets and dirty/writeback states. This changes behavior for tmpfs files to now always report zeroes in their dirty and writeback counters. This is okay as tmpfs doesn't follow conventional writeback cache behavior: its pages get "cleaned" during swapout, after which they're no l
Red Hat
kernel: mm: cachestat: fix folio read-after-free in cache walk
vendor_redhat·2024-03-13·CVSS 7.1
CVE-2024-26630 [HIGH] CWE-416 kernel: mm: cachestat: fix folio read-after-free in cache walk
kernel: mm: cachestat: fix folio read-after-free in cache walk
In the Linux kernel, the following vulnerability has been resolved:
mm: cachestat: fix folio read-after-free in cache walk
In cachestat, we access the folio from the page cache's xarray to compute
its page offset, and check for its dirty and writeback flags. However, we
do not hold a reference to the folio before performing these actions,
which means the folio can concurrently be released and reused as another
folio/page/slab.
Get around this altogether by just using xarray's existing machinery for
the folio page offsets and dirty/writeback states.
This changes behavior for tmpfs files to now always report zeroes in their
dirty and writeback counters. This is okay as tmpfs doesn't follow
conventional writeback cache behavior:
Debian
CVE-2024-26630: linux - In the Linux kernel, the following vulnerability has been resolved: mm: cachest...
vendor_debian·2024·CVSS 7.1
CVE-2024-26630 [HIGH] CVE-2024-26630: linux - In the Linux kernel, the following vulnerability has been resolved: mm: cachest...
In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix folio read-after-free in cache walk In cachestat, we access the folio from the page cache's xarray to compute its page offset, and check for its dirty and writeback flags. However, we do not hold a reference to the folio before performing these actions, which means the folio can concurrently be released and reused as another folio/page/slab. Get around this altogether by just using xarray's existing machinery for the folio page offsets and dirty/writeback states. This changes behavior for tmpfs files to now always report zeroes in their dirty and writeback counters. This is okay as tmpfs doesn't follow conventional writeback cache behavior: its pages get "cleaned" during swapout, after which they're no l
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/3a75cb05d53f4a6823a32deb078de1366954a804https://git.kernel.org/stable/c/ba60fdf75e89ea762bb617be578dc47f27655117https://git.kernel.org/stable/c/fe7e008e0ce728252e4ec652cceebcc62211657chttps://git.kernel.org/stable/c/3a75cb05d53f4a6823a32deb078de1366954a804https://git.kernel.org/stable/c/ba60fdf75e89ea762bb617be578dc47f27655117https://git.kernel.org/stable/c/fe7e008e0ce728252e4ec652cceebcc62211657c
2024-03-13
Published