{
  "schema_version": "1.6.1",
  "id": "RPI-CVE-2026-93116",
  "modified": "2026-10-09T11:39:44Z",
  "upstream": [
    "CVE-2026-93116"
  ],
  "published": "2026-09-17T16:10:40Z",
  "summary": "platform/x86: asus-wmi: fix resource leaks on probe failure",
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: asus-wmi: fix resource leaks on probe failure\n\nDuring driver initialization in asus_wmi_add(), various subsystems are\nregistered sequentially. However, the error path labels are out of order\nrelative to the registration sequence.\n\nSpecifically:\n1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to\n   fail_custom_fan_curve. Because this label is placed below fail_sysfs,\n   it bypasses the cleanup calls for the input device and sysfs groups,\n   which were successfully registered before, leaking those resources.\n2. If asus_screenpad_init() fails, the driver jumps to fail_screenpad.\n   Because fail_screenpad is placed below fail_backlight, it bypasses the\n   cleanup calls for backlight and rfkill, leaking those resources.\n\nFix these resource leaks by reordering the error path labels in\nasus_wmi_add() to match the exact reverse order of the resource\nallocations.",
  "severity": [
    {
      "type": "CVSS_V3",
      "score": "CVSS:3.1/AV:L/AC:H/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": null,
            "compiled_filter": false
          }
        }
      }
    }
  ],
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93116"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/3308b8c5f5a28403611a2f5a46f06aabe4f0c661"
    },
    {
      "type": "FIX",
      "url": "https://git.kernel.org/stable/c/ef3daa2b84a2b8499ce9e2ce1c865dca36d39f95"
    }
  ],
  "database_specific": {
    "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git",
    "upstream_modified": "2026-09-18T17:55:42Z",
    "severity": {
      "source": "kernel CNA",
      "cvss_v3_score": 7.0,
      "cvss_v3_severity": "High",
      "scenario": "AV:L - The leak is created in asus_wmi_add() called from asus_wmi_probe() during asus_wmi_register_driver()'s platform_create_bundle() for asus-nb-wmi/eeepc-wmi module init; leftover rfkill objects are later driven via /dev/rfkill (rfkill_fop_write), not by a network or radio protocol message.\nAC:H - The dangling asus_rfkill exists only when asus_screenpad_init() returns an error other than -ENODEV after asus_wmi_rfkill_init() has registered devices, which requires an ACPI WMI failure from asus_wmi_get_devstate()/asus_wmi_evaluate_method() or backlight_device_register() failure that the attacker cannot induce.\nPR:L - After fail_screenpad skips asus_wmi_rfkill_exit(), the leaked rfkill stays on rfkill_list; rfkill_fop_write() has no capable() check, so a local session user who can open /dev/rfkill (typical laptop rfkill group/uaccess) can send RFKILL_OP_CHANGE and reach asus_rfkill_set() without CAP_SYS_ADMIN.\nUI:N - The attacker themselves writes RFKILL_OP_CHANGE/CHANGE_ALL to /dev/rfkill targeting the leaked asus-wlan/asus-bluetooth rfkill idx; no other user must mount media, plug a device, or confirm a prompt.\nS:U - kfree(asus) on the asus_wmi_add() fail_screenpad path and the later asus_rfkill_query()/asus_rfkill_set() dereference of priv->asus occur in the host kernel; this is not a KVM/Xen guest escape or IOMMU/DMA bypass.\nC:H - fail_screenpad jumps past asus_wmi_rfkill_exit() and then kfree(asus) while rfkill->data still points at the embedded struct asus_rfkill; rfkill_set_block() calls asus_rfkill_query(), which reads priv->asus and priv->dev_id from that freed object, a kernel UAF read.\nI:H - The same dangling rfkill->data is passed to asus_rfkill_set()/asus_rfkill_wlan_set(), which use priv->asus->driver and mutex_lock(&asus->wmi_lock); the leaked backlight_device also keeps bl_get_data()==asus for update_bl_status(), so reclaiming the freed asus_wmi object is a write/control-flow primitive.\nA:H - asus_rfkill_query() and asus_rfkill_set() dereference the kfree'd struct asus_wmi, and asus_rfkill_wlan_set() takes asus->wmi_lock in freed memory, which oopses; fail_custom_fan_curve also skips asus_wmi_input_exit(), leaving a registered input_dev until reboot."
    }
  }
}