CVE-2026-93116 in Linux
Summary
by MITRE • 09/18/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified within the Linux kernel's platform/x86/asus-wmi driver represents a classic instance of improper cleanup during initialization failure, specifically categorized under CWE-401: Missing Release of Resource after Effective Lifetime. This flaw occurs in the asus_wmi_add() function, which is responsible for initializing various hardware-specific subsystems such as custom fan curves, screenpad input devices, backlight controls, and rfkill switches. During normal operation, these resources are allocated and registered with their respective kernel subsystems to enable user interaction and hardware control. However, when the initialization process encounters an error at any stage after some resources have already been successfully claimed, the driver must execute a reverse-order cleanup sequence to prevent resource leaks.
The technical root cause of this vulnerability lies in the misalignment between the order of resource registration and the placement of error handling labels within the source code. In C-based kernel drivers, it is standard practice to label each potential failure point so that subsequent failures can trigger the release of all previously allocated resources. In this specific case, the fail_custom_fan_curve label was positioned below the cleanup calls for sysfs groups and input devices. Consequently, if asus_wwi_custom_fan_curve_init() fails, execution jumps to a location in the code that does not invoke the necessary unregistration functions for the earlier subsystems. Similarly, the fail_screenpad label is placed after the backlight and rfkill cleanup routines are defined but potentially bypassed or incorrectly sequenced relative to their allocation order. This structural defect means that resources allocated prior to the failure point remain active in kernel memory even though the driver has failed to initialize completely.
The operational impact of this vulnerability extends beyond simple memory consumption, although resource leaks do contribute to gradual system degradation over time if drivers are repeatedly loaded and unloaded or if initialization fails frequently under certain hardware conditions. More critically, leaving subsystems registered without a corresponding valid driver instance can lead to undefined behavior when user-space applications attempt to interact with these interfaces. For example, an input device node might appear in the filesystem but fail to process events correctly because its internal state is inconsistent due to missing cleanup of dependent structures like sysfs groups. This inconsistency violates the principle of atomic initialization and can cause subsequent kernel operations involving these devices to crash or behave unpredictably, potentially affecting system stability on ASUS laptops that rely on this driver for hardware management features such as keyboard backlighting, fan speed control, and wireless radio toggling.
From a threat modeling perspective aligned with MITRE ATT&CK techniques, while this is not directly exploitable by an external attacker to gain immediate privilege escalation or remote code execution in the traditional sense, it aligns with CWE-401 which can be leveraged in denial-of-service scenarios through resource exhaustion if triggered repeatedly. It also reflects poor defensive coding practices that could mask more severe issues during fuzzing or stress testing of kernel modules. The vulnerability is effectively resolved by reordering the error path labels within asus_wmi_add() to strictly follow the reverse order of resource allocation. This ensures that every subsystem registered prior to a failure point is properly unregistered and freed before the function returns an error code, thereby maintaining system integrity and preventing memory leaks associated with incomplete driver initialization sequences.