CVE-2026-98971 in Linux
Summary
by MITRE • 10/23/2026
In the Linux kernel, the following vulnerability has been resolved:
gpio: exar: initialize the ID before registering its cleanup
devm_add_action_or_reset() invokes the cleanup action immediately when registering the action fails. gpio_exar_probe() currently stores the allocated ID in exar_gpio only after registering the action, so that failure makes exar_devm_ida_free() release ID 0. If the allocated ID is nonzero, this leaks that ID and can free ID 0 belonging to another device.
Store the ID before registering the cleanup action so both the immediate failure path and normal device teardown release the correct allocation.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in the Linux kernel's GPIO subsystem for Exar devices stems from a critical ordering error during resource initialization, specifically involving the management of dynamically allocated identifiers within an IDR (ID Radix Tree) structure. The core technical flaw lies in the sequence of operations performed by the gpio_exar_probe function relative to the registration of device-managed cleanup actions via devm_add_action_or_reset. This kernel API is designed to automatically invoke a specified cleanup handler when the associated device is released or if initialization fails partway through. However, the implementation currently registers this cleanup action before storing the newly allocated ID into the exar_gpio data structure. Consequently, if any subsequent step in the probe function fails and triggers an immediate rollback via devm_add_action_or_reset, the cleanup routine exar_devm_ida_free is invoked while the ID field remains uninitialized or holds a stale value of zero rather than the actual allocated identifier.
This logic error results in two distinct but severe operational impacts depending on the state of the system at the time of failure. First, if the allocated ID was non-zero, that specific resource identifier is leaked because it is never passed to the free function during the failed initialization path. Over time, repeated failures can exhaust the pool of available IDs for Exar GPIO devices, leading to a denial of service where new instances cannot be instantiated despite having sufficient memory and hardware resources. Second, and more critically, if the cleanup routine executes with an ID value of zero due to the premature invocation before storage, it attempts to free ID 0 in the global IDR pool. Since ID 0 is often reserved or potentially allocated to another active device instance within the same subsystem, this action results in a use-after-free scenario for that other resource. This can corrupt internal kernel data structures associated with the legitimate owner of ID 0, leading to unpredictable system behavior, potential privilege escalation if exploited by local attackers, or immediate kernel panic and system crash due to memory corruption.
From a vulnerability classification perspective, this issue aligns closely with CWE-362, which describes concurrent execution race conditions involving shared resources, although in this specific context it is more accurately characterized as CWE-459: Incomplete Cleanup of Resource after Error Handling Path. The failure to properly release or correctly reference the allocated resource during an error path violates fundamental principles of robust software engineering regarding atomicity and state consistency. Furthermore, within the MITRE ATT&CK framework for enterprise security, this type of flaw can be mapped to T1059: Command and Scripting Interpreter if it allows for arbitrary code execution via memory corruption, or more broadly under resource management failures that degrade system availability. The lack of proper error handling in driver initialization routines is a common vector for stability issues in the Linux kernel ecosystem, particularly when dealing with complex subsystems like GPIO where multiple devices may share underlying ID pools.
To mitigate this vulnerability and prevent similar issues in future development, developers must ensure that all resource allocations are committed to persistent storage structures before registering any cleanup actions or proceeding to steps that might fail. In this specific case, the fix involves moving the assignment of the allocated ID into the exar_gpio structure prior to calling devm_add_action_or_reset. This ensures that regardless of whether the initialization succeeds or fails immediately after registration, the cleanup function will always operate on the correct, valid identifier. Additionally, rigorous code review processes should emphasize checking for proper ordering in probe functions and utilizing static analysis tools capable of detecting uninitialized variable usage in error paths. System administrators can mitigate risks by ensuring their kernels are updated to versions where this patch is applied, thereby preventing potential denial-of-service conditions or memory corruption exploits arising from improper resource management in Exar GPIO drivers.