{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-64318",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-64318"
  ],
  "published": "2026-07-25T08:51:45Z",
  "summary": "partitions: aix: bound the pp_count scan to the ppe array",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npartitions: aix: bound the pp_count scan to the ppe array\n\naix_partition() reads the physical volume descriptor into a fixed-size\nstruct pvd and then scans its physical-partition-extent array:\n\n\tint numpps = be16_to_cpu(pvd->pp_count);\n\t...\n\tfor (i = 0; i < numpps; i += 1) {\n\t\tstruct ppe *p = pvd->ppe + i;\n\t\t...\n\t\tlp_ix = be16_to_cpu(p->lp_ix);\n\npvd points at a single kmalloc()'d struct pvd whose ppe[] member holds a\nfixed ARRAY_SIZE(pvd->ppe) (1016) entries, but the loop runs up to the\non-disk pp_count.  pp_count is an unvalidated __be16 read straight from\nthe descriptor, so a crafted AIX image with pp_count larger than 1016\ndrives the loop to read pvd->ppe[i] past the end of the allocation (up\nto 65535 entries, ~2 MB out of bounds).\n\nThe partition scan runs without mounting anything, when a block device\nwith a crafted AIX/IBM partition table appears (an attacker-supplied\nimage attached with losetup -P, or a device auto-scanned by udev), via\nmsdos_partition() -> aix_partition().\n\nClamp the scan to the number of entries the ppe[] array can hold.",
  "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.1.47-1+rpt4"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-2712",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v6",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l",
            "binary_version": "1:6.1.47-1+rpt4"
          },
          {
            "binary_name": "linux-image-6.1.0-rpi3-rpi-v8",
            "binary_version": "1:6.1.47-1+rpt4"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.1.47-1+rpt4": {
            "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e",
            "upstream_version": "6.1.47",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.1.178",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-64318"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/09861651617ba0fec089e8b9477439e68398c110"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/5eacdb1967378f5e5591cd27a2d8cdee2df1a599"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/b5e9c09309e18fd9839ad007c238120353ca0cc4"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/fd94a779020f2ecc8b2607f4c20b34acb1763b9a"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/4671bb74bba05fdd4acf670a35758c29e8c97b83"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/ce93228e2193a17d2c58b656e439bb39fe5c3af8"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/44f37ee92fdcd377c41bdf6a31cdd8cc7d4c410e"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/2dc0bfd2fe355fb930de63c2f2eb8ced8570c579"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-17T05:24:08Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.1,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - An attacker with local code execution can supply a crafted image through an unprivileged UDisks loop-setup operation with partition scanning enabled. No network protocol directly invokes this parser.\nAC:L - On an affected build, attacker-controlled on-disk fields deterministically reach the oversized scan without a race or memory-layout requirement for triggering the out-of-bounds access.\nPR:L - A basic active desktop user can request loop setup through UDisks under its default policy, while the kernel loop configuration path itself has no capability check. Initial-namespace root is not required in this deployment.\nUI:N - The attacker can initiate loop setup and partition scanning directly, without requiring another user to mount or open the image.\nS:U - The vulnerable partition parser and the affected kernel memory belong to the same operating-system security authority, with no demonstrated VM, IOMMU, or sandbox boundary crossing.\nC:H - The attacker-controlled count can cause 16-bit reads across nearly 2 MiB beyond the approximately 32 KiB allocation, sampling unrelated kernel memory. This is substantially more than a small bounded disclosure.\nI:N - The faulty accesses are reads; the derived logical-volume index is range-checked, and subsequent writes remain within the allocated lvip and partition-state arrays. No out-of-bounds write or control-flow write primitive is present.\nA:H - The slab out-of-bounds access is KASAN-confirmed and can produce an oops or panic on hardened kernels or when the traversal reaches inaccessible memory. An attacker can repeat partition scans to sustain denial of service."
    }
  }
}