{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2025-38172",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2025-38172"
  ],
  "published": "2025-07-03T08:36:23Z",
  "summary": "erofs: avoid using multiple devices with different type",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: avoid using multiple devices with different type\n\nFor multiple devices, both primary and extra devices should be the\nsame type. `erofs_init_device` has already guaranteed that if the\nprimary is a file-backed device, extra devices should also be\nregular files.\n\nHowever, if the primary is a block device while the extra device\nis a file-backed device, `erofs_init_device` will get an ENOTBLK,\nwhich is not treated as an error in `erofs_fc_get_tree`, and that\nleads to an UAF:\n\n  erofs_fc_get_tree\n    get_tree_bdev_flags(erofs_fc_fill_super)\n      erofs_read_superblock\n        erofs_init_device  // sbi->dif0 is not inited yet,\n                           // return -ENOTBLK\n      deactivate_locked_super\n        free(sbi)\n    if (err is -ENOTBLK)\n      sbi->dif0.file = filp_open()  // sbi UAF\n\nSo if -ENOTBLK is hitted in `erofs_init_device`, it means the\nprimary device must be a block device, and the extra device\nis not a block device. The error can be converted to -EINVAL.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H"
    }
  ],
  "affected": [
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:12",
        "name": "linux"
      },
      "versions": [
        "1:6.12.25-1+rpt1"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.12.25+rpt-rpi-2712",
            "binary_version": "1:6.12.25-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.12.25+rpt-rpi-v6",
            "binary_version": "1:6.12.25-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.12.25+rpt-rpi-v7",
            "binary_version": "1:6.12.25-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.12.25+rpt-rpi-v7l",
            "binary_version": "1:6.12.25-1+rpt1"
          },
          {
            "binary_name": "linux-image-6.12.25+rpt-rpi-v8",
            "binary_version": "1:6.12.25-1+rpt1"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.12.25-1+rpt1": {
            "linux_commit": "3dd2c2c507c271d411fab2e82a2b3b7e0b6d3f16",
            "upstream_version": "6.12.25",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.12.34"
          }
        }
      }
    },
    {
      "package": {
        "ecosystem": "Raspberry Pi OS:13",
        "name": "linux"
      },
      "versions": [
        "1:6.12.25-1+rpt1+trixie"
      ],
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "linux-image-6.12.25+rpt-rpi-2712",
            "binary_version": "1:6.12.25-1+rpt1+trixie"
          },
          {
            "binary_name": "linux-image-6.12.25+rpt-rpi-v6",
            "binary_version": "1:6.12.25-1+rpt1+trixie"
          },
          {
            "binary_name": "linux-image-6.12.25+rpt-rpi-v7",
            "binary_version": "1:6.12.25-1+rpt1+trixie"
          },
          {
            "binary_name": "linux-image-6.12.25+rpt-rpi-v8",
            "binary_version": "1:6.12.25-1+rpt1+trixie"
          },
          {
            "binary_name": "linux-image-6.12.25+rpt-rpi-v8-rt",
            "binary_version": "1:6.12.25-1+rpt1+trixie"
          }
        ]
      },
      "database_specific": {
        "per_version": {
          "1:6.12.25-1+rpt1+trixie": {
            "linux_commit": "3dd2c2c507c271d411fab2e82a2b3b7e0b6d3f16",
            "upstream_version": "6.12.25",
            "assessment": "commit ancestry (strak rule)",
            "upstream_fixed": "6.12.34"
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-38172"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/65115472f741ca000d7ea4a5922214f93cd1516e"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/cd04beb9ce2773a16057248bb4fa424068ae3807"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/9748f2f54f66743ac77275c34886a9f890e18409"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T12:19:11Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The vulnerability is reached only through the local mount(2)/fsconfig(2)+fsmount(2) filesystem-mount path on an erofs image plus its `device=` parameters; there is no network-facing consumer of this code.\nAC:L - The trigger is fully deterministic \u2014 an erofs image whose on-disk device table count matches the supplied `device=` options, with one such path naming a regular file instead of a block device, reliably yields -ENOTBLK and the use-after-free write on every attempt. Heap reuse of the freed `erofs_sb_info` is attacker-assisted because the free\u2192write window spans an attacker-influenceable `filp_open()` path walk that can be stalled arbitrarily, and the spray runs from the attacker's own threads.\nPR:N - The attacker needs no account or capability on the target: they only supply the malicious erofs image and/or arrange the `device=` path (which is resolved with symlink following at fill_super time, in directories such as container blob/staging dirs) to be a non-block file, while a privileged mounter \u2014 automounter, container/composefs runtime, or mount helper handling multi-device erofs images \u2014 performs the mount. This matches the kernel CNA treatment of crafted-image mount bugs (e.g. CVE-2025-38204, CVE-2025-38230, CVE-2025-38652).\nUI:R - The flaw only fires when someone mounts the attacker-supplied erofs image with the corresponding `device=` parameters; it cannot be triggered without that mount action.\nS:U - The freed object, the corrupted slab memory, and the resulting crash or escalation are all inside the kernel's own security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - `file_inode(sbi->dif0.file)->i_mode` is read back out of the freed `erofs_sb_info`; if a sprayed object has taken the slot the kernel dereferences an attacker-groomed pointer and reads memory at an attacker-chosen location, and use-after-free of a kmalloc object is generally leverageable into kernel-memory disclosure.\nI:H - `sbi->dif0.file = file` writes a valid kernel `struct file *` at a fixed offset (16) into a freed generic-kmalloc chunk, clobbering whatever live object has been reallocated there \u2014 a classic UAF write primitive that overwrites pointers/state of an unrelated kernel object and is a strong stepping stone to control-flow hijacking.\nA:H - Even without grooming, the UAF read of poisoned/reused memory and the follow-on `get_tree_nodev()` path (which calls `erofs_fc_fill_super()` with `s_fs_info == NULL`, immediately writing through a NULL `sbi`) produce a kernel oops/panic, and the path also leaks a `struct file` reference on every attempt."
    }
  }
}