CVE-2026-93116
High · 7.0CVSS
7.0
EPSS
0.2%
Published
Sep 17, 2026
CISA due date
—
Cloudanix analysis
A coding mistake in a Linux driver for certain ASUS laptops can waste system memory when hardware setup does not complete successfully.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- High
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Other
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Incorrect ordering of error-path labels in asus_wmi_add() causes successful registrations of input devices, sysfs groups, backlight, and rfkill to be skipped during cleanup when later initialization steps fail, resulting in resource leaks.
Why it matters to the business
On systems using the affected ASUS WMI driver, repeated probe failures can gradually exhaust kernel memory or file handles, potentially leading to degraded performance or instability on laptops with this hardware; low urgency given lack of known exploitation and stable low exploit probability.
How an attack unfolds
An attacker with local access triggers repeated driver probe failures (for example by inducing hardware or initialization errors) to accumulate leaked kernel resources; no named threat actors or campaigns are associated with this issue and public exploit maturity remains none.
How to fix it
Update the Linux kernel to a version containing the corrected error-label ordering in platform/x86/asus-wmi; rebuild and reinstall the module if using out-of-tree builds, then reboot and verify the driver loads cleanly.
How to confirm the fix worked
Confirm the presence of the reordered fail_* labels in asus_wmi_add() by inspecting the source or running the fixed driver through probe-failure test cases; monitor kernel memory statistics before and after simulated failures to verify no incremental leaks.
Typical attack path
- Obtain local access to an affected Linux system
- Induce conditions that cause asus_wmi_add() to fail after partial registration
- Repeat to accumulate leaked resources until system impact occurs
How to detect it
Review kernel logs for repeated asus_wmi probe failures followed by increasing memory or handle usage; examine dmesg or journalctl output around driver load times for signs of partial initialization without corresponding cleanup messages.
What your security team should do
- Prioritize kernel updates on ASUS laptop fleets within normal patching cycles
- Include the asus-wmi driver in regression testing for probe and error paths
- Monitor EPSS and KEV status for any future increase in exploit activity
The record
In the Linux kernel, the following vulnerability has been resolved: platform/x86: asus-wmi: fix resource leaks on probe failure During driver initialization in asus_wmi_add(), various subsystems are registered sequentially. However, the error path labels are out of order relative to the registration sequence. Specifically: 1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to fail_custom_fan_curve. Because this label is placed below fail_sysfs, it bypasses the cleanup calls for the input device and sysfs groups, which were successfully registered before, leaking those resources. 2. If asus_screenpad_init() fails, the driver jumps to fail_screenpad. Because fail_screenpad is placed below fail_backlight, it bypasses the cleanup calls for backlight and rfkill, leaking those resources. Fix these resource leaks by reordering the error path labels in asus_wmi_add() to match the exact reverse order of the resource allocations.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|