{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2024-26630",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2024-26630"
  ],
  "published": "2024-03-13T15:50:47Z",
  "summary": "mm: cachestat: fix folio read-after-free in cache walk",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: cachestat: fix folio read-after-free in cache walk\n\nIn cachestat, we access the folio from the page cache's xarray to compute\nits page offset, and check for its dirty and writeback flags.  However, we\ndo not hold a reference to the folio before performing these actions,\nwhich means the folio can concurrently be released and reused as another\nfolio/page/slab.\n\nGet around this altogether by just using xarray's existing machinery for\nthe folio page offsets and dirty/writeback states.\n\nThis changes behavior for tmpfs files to now always report zeroes in their\ndirty and writeback counters.  This is okay as tmpfs doesn't follow\nconventional writeback cache behavior: its pages get \"cleaned\" during\nswapout, after which they're no longer resident etc.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.6.20-1+rpt1"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-2712",
            "binary_version": "1:6.6.20-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-v6",
            "binary_version": "1:6.6.20-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-v7",
            "binary_version": "1:6.6.20-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-v7l",
            "binary_version": "1:6.6.20-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.6.20+rpt-rpi-v8",
            "binary_version": "1:6.6.20-1+rpt1"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.6.20-1+rpt1": {
            "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668",
            "upstream_version": "6.6.20",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.6.21"
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-26630"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/ba60fdf75e89ea762bb617be578dc47f27655117"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/fe7e008e0ce728252e4ec652cceebcc62211657c"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3a75cb05d53f4a6823a32deb078de1366954a804"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T11:52:36Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.1,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The vulnerability is reached only through the local `cachestat(2)` system call on an open file descriptor. There is no remote or adjacent-network path to `filemap_cachestat()`.\nAC:L - Although this is a race, the attacker drives both sides of it: one thread loops on `cachestat()` while another loops `POSIX_FADV_DONTNEED`/truncate on a file it owns (e.g. a memfd) plus a slab-spray thread, so the window is created and retried at will with no dependence on conditions outside the attacker's control.\nPR:L - The syscall performs no capability or permission check beyond `fdget()` \u2014 any unprivileged local user with any open file descriptor can call it, and `CONFIG_CACHESTAT_SYSCALL` is `default y` in stock kernels.\nUI:N - The attacker's own processes populate the page cache, evict it, and call the syscall; no victim action is needed at any point.\nS:U - The read-after-free occurs in kernel memory and the disclosed data is returned to the calling process within the same security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - Reading the freed-and-reused `struct page` leaks stale metadata whose reuse the attacker can groom, and the pointer-sized `folio->index` value (SLUB's `slab.freelist`) is recoverable exactly from the returned `nr_cache` counter, giving repeatable full kernel-heap address disclosure and KASLR defeat.\nI:N - Every access to the freed folio on this path is a read; the results are accumulated into a stack `struct cachestat` copied to the caller's own buffer, so no kernel memory is modified and no write primitive is created.\nA:H - This is a use-after-free, which crashes even when not exploited: a stale `PG_head` bit sends the read to `page[1]`, which can fault on an unpopulated vmemmap section on memory-hole/hotplug systems, and KASAN-instrumented kernels panic on the UAF report."
    }
  }
}