{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2024-39495",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2024-39495"
  ],
  "published": "2024-07-12T12:21:19Z",
  "summary": "greybus: Fix use-after-free bug in gb_interface_release due to race condition.",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngreybus: Fix use-after-free bug in gb_interface_release due to race condition.\n\nIn gb_interface_create, &intf->mode_switch_completion is bound with\ngb_interface_mode_switch_work. Then it will be started by\ngb_interface_request_mode_switch. Here is the relevant code.\nif (!queue_work(system_long_wq, &intf->mode_switch_work)) {\n\t...\n}\n\nIf we call gb_interface_release to make cleanup, there may be an\nunfinished work. This function will call kfree to free the object\n\"intf\". However, if gb_interface_mode_switch_work is scheduled to\nrun after kfree, it may cause use-after-free error as\ngb_interface_mode_switch_work will use the object \"intf\".\nThe possible execution flow that may lead to the issue is as follows:\n\nCPU0                            CPU1\n\n                            |   gb_interface_create\n                            |   gb_interface_request_mode_switch\ngb_interface_release        |\nkfree(intf) (free)          |\n                            |   gb_interface_mode_switch_work\n                            |   mutex_lock(&intf->mutex) (use)\n\nFix it by canceling the work before kfree.",
  "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.95",
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-39495"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/74cd0a421896b2e07eafe7da4275302bfecef201"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/2b6bb0b4abfd79b8698ee161bb73c0936a2aaf83"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/fb071f5c75d4b1c177824de74ee75f9dd34123b9"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/9a733d69a4a59c2d08620e6589d823c24be773dc"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/0b8fba38bdfb848fac52e71270b2aa3538c996ea"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/03ea2b129344152157418929f06726989efc0445"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/5c9c5d7f26acc2c669c1dcf57d1bb43ee99220ce"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-08-05T11:52:36Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.8,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The attacker-controlled side of the race is the FW_MGMT_IOC_MODE_SWITCH ioctl on the /dev/gb-fw-mgmt-N character device (drivers/staging/greybus/fw-management.c:503), the sole caller of gb_interface_request_mode_switch(). Greybus is a local bus (USB/UART/serdev transport), not remotely reachable, so exploitation requires local access to the system.\nAC:L - The attacker directly controls the work-queueing side via the ioctl and can retry it in a tight loop indefinitely, while the free side (interface refcount drop via module removal / SVC teardown) can be induced repeatedly by hot-unplug or the 2-second mode-switch timeout path that calls gb_interface_deactivate(). Heap grooming of the ~1KB gb_interface allocation is standard, so the attacker creates and wins the race himself rather than depending on conditions outside his control.\nPR:L - fw_mgmt_ioctl() and fw_mgmt_ioctl_unlocked() contain no capable() or CAP_* check at all; the only gate is the permission on the /dev/gb-fw-mgmt-N node, which on greybus-based embedded/mobile deployments is routinely granted to a non-root firmware-management service or group. An unprivileged user holding a descriptor to that node can drive the entire path.\nUI:N - No victim action is needed \u2014 the attacker issues the ioctl himself, and the freeing side is driven by SVC module-removed events or the mode-switch timeout that the attacker can provoke. No file must be opened and no filesystem mounted by another user.\nS:U - The use-after-free corrupts kernel heap memory and is exploited within the same kernel security authority; there is no hypervisor, IOMMU, or sandbox boundary crossed. This is standard local kernel privilege escalation.\nC:H - The freed gb_interface can be reclaimed and sprayed by the attacker, after which gb_interface_mode_switch_work() reads intf->control, intf->enabled and walks intf->bundles, giving a controlled-pointer dereference usable as an arbitrary kernel-memory read primitive. Full disclosure of kernel memory, including credentials and KASLR-defeating pointers, is achievable.\nI:H - mutex_lock(&intf->mutex) on the freed object writes into attacker-controlled reclaimed memory, and gb_bundle_destroy() iterating the stale intf->bundles list performs list-unlink writes through attacker-supplied pointers. These are classic UAF write primitives that can be escalated to control-flow hijack and full kernel compromise.\nA:H - Even without successful reclaim, the work item dereferences and takes a mutex on freed memory, producing a kernel oops or panic. Any use-after-free of this kind reliably crashes the system, and the ioctl can be repeated to trigger it at will."
    }
  }
}