{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-89599",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-89599"
  ],
  "published": "2026-09-11T19:47:07Z",
  "summary": "fbdev: omapfb: panel-dsi-cm: initialize lock before registering display",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: omapfb: panel-dsi-cm: initialize lock before registering display\n\ndsicm_probe() registers the display before initializing ddata->lock.\nOnce omapdss_register_display() publishes the display, another consumer\ncan reach a dsicm callback that takes this mutex while it is still\nuninitialized.\n\nInitialize the mutex before registering the display so the published\ncallbacks always see a valid lock.",
  "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.188",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-89599"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/ef20d4e17d7fb0d83144caa9667e6f3198288993"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/e7023d18c4eb292f886b31a3576402cb0e357df7"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/f33a96e49284589257e90ddc4394ec0c6bf11ec4"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/302d19fbc7dc7e9f498930c66d65ff711ba5ba9f"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/2c3f8c9c995db185284b079f39177e85b2258176"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/76818e81cfcae33b09b739de09162c7d8d89bf0b"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/09db79078f25c048cfb5d7849795c70415ab8574"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/f8e43fe0f22b7137ce456e6fe3581d3098174f74"
    }
  ],
  "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": 8.4,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The bug is in the OMAP DSI command-mode panel driver: dsicm_probe() publishes dsicm_ops via omapdss_register_display(), and those callbacks are reached from local omapfb probe, FBIOBLANK, and omapfb ioctls on /dev/fb*. There is no network, Bluetooth/WiFi, or USB protocol path into this code.\nAC:L - On preemptible kernels dsicm_probe() can be preempted after omapdss_register_display() adds the panel to panel_list and before mutex_init(&ddata->lock). Concurrent omapfb_probe then calls dsicm_enable/enable_te/update on that published device, so the race is driven by the in-kernel consumer rather than an uninfluenced hardware lottery.\nPR:N - dsicm_probe() and the omapfb consumer (omapfb_init_display \u2192 driver->enable/update) run from platform/deferred probe during boot on boards with an omapdss,panel-dsi-cm node. That path has no capable() or credential check and needs no OS account.\nUI:N - Display registration and omapfb\u2019s subsequent enable/update run automatically during device enumeration on affected TI OMAP systems; no victim must open /dev/fb*, write sysfs, or mount a filesystem.\nS:U - Uninitialized-mutex use and any follow-on lock or DSI-state corruption remain inside the host omapfb/omapdss driver. This is not a VM escape, IOMMU bypass, or other cross-authority impact.\nC:H - A consumer that wins the race mutex_lock()s kzalloc\u2019d ddata->lock (NULL wait_list); probe can then mutex_init() a lock another thread still holds so two threads enter dsicm_enable/update. That lock-state corruption is kernel memory-unsafety that can be leveraged for disclosure, not a small bounded leak.\nI:H - mutex_init() of a mutex another thread still holds resets owner and wait_list while dsicm callbacks run unsynchronized against DSI bus and panel_drv_data state, giving write and control-flow primitives rather than a pure crash.\nA:H - CONFIG_DEBUG_MUTEXES treats lock-used-without-init as an oops, and a corrupted mutex wait_list or double-entry into DSI enable/disable causes a kernel oops, panic, or hang, fully denying availability."
    }
  }
}