CVE-2026-98397 in Linux
Summary
by MITRE • 10/14/2026
In the Linux kernel, the following vulnerability has been resolved:
platform/x86: x86-android-tablets: hold device reference for secondary fwnode teardown
In gpio_secondary_fwnode_init(), acpi_bus_find_device_by_name() returns a device reference, but the local dev variable is declared with __free(put_device), dropping the reference at the end of each iteration. Meanwhile, devm_add_action_or_reset() saves the dev pointer for gpio_secondary_unset() without incrementing its reference count, which could lead to a use-after-free during driver teardown if the device is released in the interim.
Acquire an explicit device reference with get_device() when registering the devres action, and drop it with put_device() inside gpio_secondary_unset().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified within the Linux kernel's platform/x86 subsystem specifically affects the x86-android-tablets driver module involves a critical use-after-free condition arising from improper reference counting management during device initialization and teardown. The core of this issue lies in the interaction between ACPI bus device lookup mechanisms and managed resource cleanup routines. When initializing secondary firmware node data through gpio_secondary_fwnode_init, the function acpi_bus_find_device_by_name returns a pointer to an underlying struct device along with an associated reference count that must be properly maintained by the caller to ensure the object remains valid in memory. However, due to the use of compiler attributes such as __free(put_device) on local variables within iterative loops or initialization blocks, the kernel automatically invokes put_device upon exiting the scope, thereby decrementing and potentially releasing the device reference prematurely relative to its actual usage lifecycle.
This premature release creates a dangerous window where the driver retains a pointer to the device structure for later cleanup operations via devm_add_action_or_reset, which registers gpio_secondary_unset as a teardown handler. The function devm_add_action_or_reset stores this raw pointer without incrementing the reference count, assuming that the referenced object will remain alive until the managed resource is freed. If the ACPI bus subsystem or another component releases the device before the driver's own cleanup phase executes, the stored pointer becomes dangling. Subsequent execution of gpio_secondary_unset during system shutdown or module unloading attempts to access memory associated with a already-freed struct device, triggering a use-after-free vulnerability that can lead to kernel panics, data corruption, or potentially arbitrary code execution if an attacker can influence the allocation patterns in the slab cache where the freed object resides.
From a classification perspective, this flaw aligns closely with CWE-416, Use After Free, as it involves accessing memory after it has been released back to the system allocator without proper synchronization of lifecycles between reference holders and consumers. In terms of adversarial behavior mapping under MITRE ATT&CK for Enterprise or ICS, while primarily a stability issue rather than an explicit exploit vector in most default configurations, such vulnerabilities fall under T1059 Command and Scripting Interpreter if leveraged via kernel exploitation techniques to gain privilege escalation, though more accurately they represent foundational memory safety violations often exploited in conjunction with other flaws like out-of-bounds writes. The lack of atomic reference counting adjustments between the acquisition phase and the registration of cleanup actions breaks the fundamental contract required for safe asynchronous resource management in the Linux kernel driver model.
The operational impact of this vulnerability is significant, particularly on x86-based Android tablet devices where ACPI tables define complex hardware configurations involving GPIO controllers managed through firmware nodes. During normal operation, the system may remain stable if no concurrent device removal events occur. However, under conditions such as hot-plug scenarios, dynamic module loading and unloading, or aggressive power management states that trigger early teardown sequences, the race condition becomes exploitable. A local attacker with sufficient privileges to load kernel modules or trigger specific ACPI event handling paths could potentially crash the system by forcing a sequence of events that results in the premature release of the device structure before gpio_secondary_unset is invoked. This denial-of-service impact compromises system reliability and availability, which are critical for embedded tablet environments often used in industrial or public-facing deployments where uptime is paramount.
To mitigate this vulnerability, developers must ensure strict adherence to reference counting protocols when interacting with kernel objects that have independent lifecycles managed by subsystems like ACPI. The resolution involves explicitly acquiring an additional device reference using get_device immediately after retrieving the pointer from acpi_bus_find_device_by_name and before registering it via devm_add_action_or_reset. This ensures that the object's lifetime extends at least until the registered cleanup function gpio_secondary_unset is called. Furthermore, within gpio_secondary_unset, a corresponding put_device call must be executed to balance the reference count acquired earlier, preventing memory leaks while maintaining safety against premature deallocation. This pattern of explicit get and paired put operations decouples the lifecycle management from automatic scope-based cleanup attributes that do not account for cross-component dependencies.
System administrators should apply kernel updates provided by their distribution vendors as soon as patches incorporating this fix are available. For environments where immediate patching is not feasible, mitigations include avoiding dynamic unloading of the x86-android-tablets module and ensuring stable ACPI device states during runtime operations to minimize race conditions. Long-term architectural improvements involve auditing all instances in the kernel tree where devm_add_action_or_reset or similar managed resource functions are used with pointers obtained from subsystem-specific lookup APIs that return references, verifying that reference counts are correctly adjusted to prevent dangling pointer scenarios across the entire driver stack.