{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-46270",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-46270"
  ],
  "published": "2026-06-03T15:49:47Z",
  "summary": "power: supply: rt9455: Fix use-after-free in power_supply_changed()",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npower: supply: rt9455: Fix use-after-free in power_supply_changed()\n\nUsing the `devm_` variant for requesting IRQ _before_ the `devm_`\nvariant for allocating/registering the `power_supply` handle, means that\nthe `power_supply` handle will be deallocated/unregistered _before_ the\ninterrupt handler (since `devm_` naturally deallocates in reverse\nallocation order). This means that during removal, there is a race\ncondition where an interrupt can fire just _after_ the `power_supply`\nhandle has been freed, *but* just _before_ the corresponding\nunregistration of the IRQ handler has run.\n\nThis will lead to the IRQ handler calling `power_supply_changed()` with\na freed `power_supply` handle. Which usually crashes the system or\notherwise silently corrupts the memory...\n\nNote that there is a similar situation which can also happen during\n`probe()`; the possibility of an interrupt firing _before_ registering\nthe `power_supply` handle. This would then lead to the nasty situation\nof using the `power_supply` handle *uninitialized* in\n`power_supply_changed()`.\n\nFix this racy use-after-free by making sure the IRQ is requested _after_\nthe registration of the `power_supply` handle.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/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.165",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46270"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/d4e2e3c3caa26b93aa9f36d0a6824b584e2a8dfc"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/62d753b916bd500bb269b7078cdab73198ab4718"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/a39f8f06216f73ef40e71e2fe4ad071964c1fd36"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/af261f218a7606f93d2c786353d60bb4feb56ef0"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/2178dc65d45e2f7bcaa8af8d80d100419bdab251"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/64e15155095f39f4dec9b4659da1238ef8fc54d4"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/721449a15170fc5f028a7576d7f65b9f60d53482"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/e2febe375e5ea5afed92f4cd9711bde8f24ee6d2"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T13:16:28Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 8.4,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - Exploitation requires local driver teardown (module unload, sysfs unbind, or shutdown/reboot) that runs `devres_release_all()`; the vulnerable `power_supply_changed()` path is only reachable from the on-chip IRQ handler during that window, not from any network-facing protocol.\nAC:L - An attacker who can initiate driver removal can repeatedly assert charger interrupts (USB plug/unplug, charge events) to hit the narrow race between `power_supply_unregister()` and IRQ release; this is a standard attacker-controlled UAF race, not a layout-dependent condition.\nPR:N - On battery-powered embedded/mobile platforms with this IC, an attacker with brief physical possession can force power-off/reboot (no Linux account or capability) while manipulating the charging port to fire IRQs during devm teardown; explicit unbind/rmmod also works but is not the only path.\nUI:N - No victim interaction is required beyond the attacker\u2019s own physical control of the device and charging port; exploitation does not depend on the victim opening files, mounting filesystems, or approving prompts.\nS:U - Impact is confined to kernel memory corruption and privilege escalation within the kernel security boundary; it does not cross VM, container, or IOMMU isolation boundaries.\nC:H - The IRQ handler calls `power_supply_changed()` on a freed `struct power_supply`, performing spinlock operations and `schedule_work()` on freed heap memory, which is a classic UAF that can be turned into arbitrary kernel memory disclosure.\nI:H - The same UAF writes to freed object fields (`changed`, locks, workqueue) and can be combined with heap grooming for arbitrary kernel writes or control-flow hijack, as noted by the fix author (\u201csilently corrupts the memory\u201d).\nA:H - Use-after-free in interrupt context typically causes immediate kernel oops/panic or silent memory corruption; the commit explicitly states this \u201cusually crashes the system.\u201d"
    }
  }
}