CVE-2026-98202 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound
Transport drivers (such as rmi_i2c and rmi_spi) invoke rmi_driver_suspend() and rmi_driver_resume() on their child rmi_dev device during system power management events. However, transport drivers are fully registered and operational even if the physical RMI driver failed to bind or probe the rmi_dev device.
When rmi_driver_suspend() or rmi_driver_resume() is called on an unbound rmi_dev, dev_get_drvdata() returns NULL. Calling rmi_disable_irq() or rmi_enable_irq() without driver data attached causes a NULL pointer dereference and General Protection Fault when attempting to lock data->enabled_mutex.
Fix this by checking if driver data is attached to rmi_dev in rmi_driver_suspend() and rmi_driver_resume(), exiting early if no driver data is present.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/07/2026
The Linux kernel input subsystem contains a vulnerability within the Synaptics RMI4 transport drivers, specifically affecting the handling of system power management events during suspend and resume operations. The core issue arises from an improper assumption regarding the binding state between transport drivers and their child devices. Transport drivers such as rmi_i2c and rmi_spi are responsible for invoking driver-level suspend and resume functions on associated RMI device structures when the system undergoes power transitions. However, these transport drivers remain fully registered and operational regardless of whether the physical RMI driver has successfully bound or probed the specific rmi_dev instance. This discrepancy creates a race condition where the kernel attempts to manage interrupts for devices that lack an active driver context.
When the suspend or resume routine is triggered for an unbound rmi_dev, the function dev_get_drvdata() returns NULL because no driver data was attached during initialization due to the failed bind operation. The code subsequently proceeds to call functions like rmi_disable_irq or rmi_enable_irq without verifying this null state. These interrupt management routines attempt to access internal structures by locking a mutex located within the driver data structure, specifically data->enabled_mutex. Since the pointer is NULL, this access results in a General Protection Fault (GPF), which manifests as a kernel panic and causes an immediate system crash or reboot during power transitions.
This vulnerability represents a classic null pointer dereference flaw that compromises system stability rather than directly enabling privilege escalation or remote code execution. From a classification perspective, the issue aligns with CWE-476, which denotes NULL Pointer Dereference, as the software fails to properly verify an object reference before using it. In terms of attack vectors and operational impact, this falls under MITRE ATT&CK technique T1595.002, Active Scanning: Vulnerability Scanning, because while not exploitable for direct compromise by a remote attacker in most contexts, the resulting denial of service through system instability can be triggered locally or potentially via automated power management scripts that induce frequent suspend-resume cycles to disrupt availability.
The resolution involves adding explicit validation checks within the rmi_driver_suspend and rmi_driver_resume functions to determine if driver data is attached to the rmi_dev structure before proceeding with interrupt manipulation. If no driver data is present, indicating an unbound device state, the functions exit early without attempting to access protected memory regions or lock mutexes. This defensive programming approach ensures that power management events are safely ignored for devices lacking a valid driver context. To mitigate this risk in environments running affected kernel versions, administrators should apply the latest available security patches and updates provided by their distribution vendors. Additionally, monitoring system logs for general protection faults during sleep transitions can help identify systems still operating with vulnerable code paths before they experience critical instability.