{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2025-37901",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2025-37901"
  ],
  "published": "2025-05-20T15:22:31Z",
  "summary": "irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs\n\nOn Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not\nhave a corresponding MPM pin and should not be handled inside the MPM\ndriver. The IRQ domain hierarchy is always applied, so it's required to\nexplicitly disconnect the hierarchy for those. The pinctrl-msm driver marks\nthese with GPIO_NO_WAKE_IRQ. qcom-pdc has a check for this, but\nirq-qcom-mpm is currently missing the check. This is causing crashes when\nsetting up interrupts for non-wake GPIOs:\n\n root@rb1:~# gpiomon -c gpiochip1 10\n   irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1\n   Unable to handle kernel paging request at virtual address ffff8000a1dc3820\n   Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT)\n   pc : mpm_set_type+0x80/0xcc\n   lr : mpm_set_type+0x5c/0xcc\n   Call trace:\n    mpm_set_type+0x80/0xcc (P)\n    qcom_mpm_set_type+0x64/0x158\n    irq_chip_set_type_parent+0x20/0x38\n    msm_gpio_irq_set_type+0x50/0x530\n    __irq_set_trigger+0x60/0x184\n    __setup_irq+0x304/0x6bc\n    request_threaded_irq+0xc8/0x19c\n    edge_detector_setup+0x260/0x364\n    linereq_create+0x420/0x5a8\n    gpio_ioctl+0x2d4/0x6c0\n\nFix this by copying the check for GPIO_NO_WAKE_IRQ from qcom-pdc.c, so that\nMPM is removed entirely from the hierarchy for non-wake GPIOs.",
  "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: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.138",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-37901"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/45aced97f01d5ab14c8a2a60f6748f18c501c3f5"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/dfbaecf7e38f5e9bfa5e47a1e525ffbb58bab8cf"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/f102342360950b56959e5fff4a874ea88ae13758"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/d5c10448f411a925dd59005785cb971f0626e032"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/38a05c0b87833f5b188ae43b428b1f792df2b384"
    }
  ],
  "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 through the GPIO character device ioctl path (`gpio_ioctl` \u2192 `linereq_create` \u2192 `edge_detector_setup` \u2192 `request_threaded_irq`), or equivalently the legacy sysfs `edge` attribute, both of which require local access to the system. There is no network or adjacent-network path to `qcom_mpm_set_type()`.\nAC:L - Triggering is fully deterministic \u2014 a single `gpiomon -c gpiochipN <line>` on any GPIO absent from the SoC's `wakeirq_map` reliably reaches the out-of-bounds access, and non-wake lines are the majority on these SoCs and are trivially enumerable. No race, no memory-layout condition outside the attacker's control is needed for the corruption/crash.\nPR:L - The attacker only needs open access to `/dev/gpiochipN`, which on the embedded, robotics and IoT platforms that actually ship Qualcomm MPM is routinely granted to an unprivileged `gpio`-group account or service user via standard udev rules (0660 root:gpio) so that libgpiod consumers can run without root. No capability check exists anywhere along the path once the device node is opened.\nUI:N - The attacker performs the ioctl themselves in a single step; no victim action, configuration change, or interaction from another user is required.\nS:U - The out-of-bounds access corrupts kernel memory within the same security authority; there is no VM, IOMMU, or sandbox boundary crossed.\nC:H - `__assign_bit(0xFFFFFFFF, &val, ...)` performs a read-modify-write 511 MB beyond a kernel stack local, i.e. an unbounded out-of-bounds read of an arbitrary vmalloc-region word; combined with the accompanying write primitive this constitutes memory corruption that can be leveraged to disclose kernel memory.\nI:H - This is an out-of-bounds write: bit 63 of the unsigned long at a fixed +0x1FFFFFF8 offset from the kernel stack is set or cleared under attacker control (via the EDGE_RISING/EDGE_FALLING line flags), repeatably. With vmap'd stacks and vmalloc grooming, flipping the top bit of a pointer, length, or refcount in a neighbouring object is a real control-flow-corruption primitive.\nA:H - The reported and reproducible outcome is a kernel paging fault (\"Unable to handle kernel paging request\") in `mpm_set_type`, an oops taken inside `raw_spin_lock_irqsave(&priv->lock)` with interrupts disabled \u2014 so `priv->lock` is orphaned and all later MPM operations, including the wake handler and the suspend path, deadlock."
    }
  }
}
