{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-64031",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-64031"
  ],
  "published": "2026-07-19T15:41:06Z",
  "summary": "erofs: fix managed cache race for unaligned extents",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix managed cache race for unaligned extents\n\nAfter unaligned compressed extents were introduced, the following race\ncould occur:\n\n[Thread 1]                                   [Thread 2]\n(z_erofs_fill_bio_vec)\n<handle a Z_EROFS_PREALLOCATED_FOLIO folio>\n...\nfilemap_add_folio (1)\n                                             (z_erofs_bind_cache)\n                                             <the same folio is found..>\n                                             ..\n                                             ..\nfolio_attach_private (2)\n                                             filemap_add_folio (3) again\n\nSince (1) is executed but (2) hasn't been executed yet, it's possible\nthat another thread finds the same managed folio in z_erofs_bind_cache()\nfor a different pcluster and calls filemap_add_folio() again since\nfolio->private is still Z_EROFS_PREALLOCATED_FOLIO.\n\nFix this by explicitly clearing folio->private before making the folio\nvisible in the managed cache so that another pcluster can simply wait\non the locked managed folio as what we did for other shared cases [1].\n\nThis only impacts unaligned data compression (`-E48bit` with zstd,\nfor example).\n\n[1] Commit 9e2f9d34dd12 (\"erofs: handle overlapped pclusters out of\n crafted images properly\") was originally introduced to handle crafted\n overlapped extents, but it addresses unaligned extents as well.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:13",
        "name": "linux"
      },
      "versions": [
        "1:6.18.29-1+rpt1",
        "1:6.18.33-1+rpt1"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.18.29+rpt-rpi-2712",
            "binary_version": "1:6.18.29-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.29+rpt-rpi-v6",
            "binary_version": "1:6.18.29-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.29+rpt-rpi-v7",
            "binary_version": "1:6.18.29-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.29+rpt-rpi-v8",
            "binary_version": "1:6.18.29-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.29+rpt-rpi-v8-rt",
            "binary_version": "1:6.18.29-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.33+rpt-rpi-2712",
            "binary_version": "1:6.18.33-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.33+rpt-rpi-v6",
            "binary_version": "1:6.18.33-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.33+rpt-rpi-v7",
            "binary_version": "1:6.18.33-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.33+rpt-rpi-v8",
            "binary_version": "1:6.18.33-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.18.33+rpt-rpi-v8-rt",
            "binary_version": "1:6.18.33-1+rpt1"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.18.29-1+rpt1": {
            "linux_commit": "66318c5b5cd8145a662303af12ed39ac07eb27cc",
            "upstream_version": "6.18.29",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.18.34"
          },
          "1:6.18.33-1+rpt1": {
            "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412",
            "upstream_version": "6.18.33",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.18.34"
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-64031"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/2718cdb6db0fdbe375e61f2980aada27bafb323e"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/425d32d6288d7d845e486af9419bbedccd8c9103"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/038166f873c4caf6e85cfd4ea0c5a5ba297b4e8b"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/649932fc3815eda2f24eb4de4b3a5e94886ee0b9"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-09-14T12:06:03Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The bug is reached only through local VFS read paths (`read`/`pread`/`mmap` faults) on a mounted EROFS volume, flowing through `z_erofs_read_folio`/`z_erofs_readahead` \u2192 `z_erofs_runqueue` \u2192 `z_erofs_submit_queue` \u2192 `z_erofs_fill_bio_vec` and `z_erofs_bind_cache`. There is no network-facing handler; exploitation requires local filesystem access.\nAC:L - The race is between concurrent read/decompress threads that the attacker fully controls by issuing parallel reads against a crafted image with overlapping unaligned compressed extents. No timing or layout conditions outside attacker control are required beyond crafting the image and spawning concurrent I/O.\nPR:L - Triggering the vulnerable managed-cache path requires mounting a crafted EROFS image with unaligned zstd extents, which is achievable with CAP_SYS_ADMIN inside an unprivileged user namespace (`unshare -Urn`) plus loop mount. After mount, only normal unprivileged file read access is needed to hit the race.\nUI:N - Once the attacker can mount the crafted image (e.g., via user namespace), exploitation is fully automated through concurrent reads and requires no additional victim interaction such as opening a specific application or clicking a link.\nS:U - Impact is confined to kernel memory corruption and privilege escalation within the same kernel/host security boundary; this is not a VM escape, IOMMU bypass, or cross-authority sandbox breakout.\nC:H - The race leaves managed folios visible in the page cache while `folio->private` still marks them preallocated, allowing duplicate `filemap_add_folio` and conflicting `folio_attach_private`/`folio_detach_private` bindings to different pclusters\u2014classic page-cache corruption that can yield arbitrary kernel memory disclosure via confused folio ownership.\nI:H - Associating one managed folio with multiple pclusters corrupts `folio->private` and compressed-bvec references, creating use-after-free/refcount confusion in the managed cache that is exploitable for arbitrary kernel writes or control-flow hijack, not merely a benign error return.\nA:H - The corrupted managed-cache state can cause kernel oops/panic, hung tasks, or deadlock (similar overlapped-pcluster crafted-image failures previously caused syzbot hangs), and any successful UAF in this path also implies high availability impact even before full exploitation."
    }
  }
}