CVE-2026-98202: Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound
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 rmii2c and rmispi) invoke rmidriversuspend() and rmidriverresume() on their child rmidev 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 rmidev device.
When rmidriversuspend() or rmidriverresume() is called on an unbound rmidev, devgetdrvdata() returns NULL. Calling rmidisableirq() or rmienableirq() without driver data attached causes a NULL pointer dereference and General Protection Fault when attempting to lock data->enabledmutex.
Fix this by checking if driver data is attached to rmidev in rmidriversuspend() and rmidriverresume(), exiting early if no driver data is present.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In rmi_driver_suspend() and rmi_driver_resume(), check whether driver data is attached to rmi_dev using dev_get_drvdata(); if no driver data is present, exit early before accessing data->enabled_mutex or invoking IRQ enable/disable operations.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel with Synaptics RMI4 transport drivers, such as rmi_i2c or rmi_spi, are exposed when the transport driver is operational but its child rmi_dev device has not successfully bound to or probed by the physical RMI driver.
What condition triggers the failure?
A system suspend or resume event must occur while the rmi_dev device is unbound. The transport driver then calls the RMI suspend or resume handler without attached driver data, causing a NULL pointer dereference and General Protection Fault.
Is this an externally exploitable vulnerability?
The provided information describes a kernel crash during power-management handling under an unbound-driver condition. It does not state that an unprivileged or remote attacker can create that condition or execute code through it.
What does the fix change?
The fix makes rmi_driver_suspend() and rmi_driver_resume() check whether driver data is attached to rmi_dev. If no driver data is present, the handlers exit without attempting to enable or disable IRQs.