Cloudanix VulnDB

CVE-2026-93124

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A driver bug on certain ASUS wireless devices could let a local user crash the whole computer by forcing the driver to attach to the wrong hardware.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

NULL pointer dereference in asus_wireless_remove() when acpi_dev_remove_notify_handler() is called with a NULL ACPI companion pointer, caused by successful probe on a device lacking an ACPI match due to driver override.

Why it matters to the business

Potential kernel crashes or denial of service on systems with ASUS wireless hardware when drivers are rebound or mismatched devices are attached, though low exploitability reduces immediate operational risk.

How an attack unfolds

An attacker with local access uses device_match_driver_override to force-bind the asus-wireless driver to a non-matching device without an ACPI companion, registers the input device, then triggers unbind to cause the NULL dereference during remove.

How to fix it

Update the Linux kernel to a version containing the fix that returns -ENODEV early in asus_wireless_probe when acpi_match_acpi_device fails; rebuild and reboot after patching.

How to confirm the fix worked

Confirm kernel source contains the early -ENODEV return before input device registration; test probe on non-matching devices and verify no NULL companion is stored; monitor for absence of the vulnerable probe path in dmesg.

Typical attack path

  1. Obtain local access on a Linux system with the vulnerable asus-wireless module
  2. Use sysfs or driver override mechanisms to force the driver onto a device lacking ACPI companion
  3. Trigger probe which succeeds despite missing match
  4. Initiate unbind or module removal to invoke asus_wireless_remove with NULL pointer
  5. Cause kernel panic via NULL dereference in acpi notify handler removal

How to detect it

Review kernel logs for asus_wireless_probe success messages followed by remove paths; inspect sysfs driver_override usage and dmesg entries around ACPI companion mismatches; correlate with unbind events on platform devices.

What your security team should do

  • Prioritize kernel updates on systems exposing the asus-wireless driver within standard patch cycles given low EPSS and no KEV listing
  • Audit custom driver bindings or overrides in ASUS hardware environments
  • Monitor kernel logs for probe success on unexpected devices
  • Test unbind/remove paths in lab environments matching the described failure

The record

In the Linux kernel, the following vulnerability has been resolved: platform/x86: asus-wireless: Fail probe when there is no ACPI match Every platform driver can be forced to match a device that does not match its list of device IDs because of device_match_driver_override(), so platform drivers that rely on the existence of a device ACPI companion object need to verify its presence. asus_wireless_probe() returns success when acpi_match_acpi_device() finds no match, leaving behind an input device that never reports anything because the notify handler is not installed. Worse, when the driver is force-bound to a device without an ACPI companion, probe still succeeds and stores a NULL companion pointer, which asus_wireless_remove() later passes to acpi_dev_remove_notify_handler(), leading to a NULL pointer dereference on unbind. Return -ENODEV when the device does not match the ID table. This also covers the missing-companion case, because acpi_match_acpi_device() rejects a NULL device. Perform the check before allocating any driver state, instead of after the input device has already been registered.

Affected packages

Ecosystem Package Introduced Fixed