Cloudanix VulnDB

CVE-2026-98202

None

CVSS

—

EPSS

0.2%

Published

Oct 6, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel's handling of certain touch controllers can make the computer crash when it tries to sleep or wake up if the driver did not load correctly.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Low
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

NULL pointer dereference in rmi_driver_suspend and rmi_driver_resume when dev_get_drvdata returns NULL on an unbound rmi_dev device, resulting in GPF during mutex operations in rmi_disable_irq or rmi_enable_irq.

Why it matters to the business

Unexpected system crashes or instability during suspend and resume operations on affected Linux kernels, increasing downtime and support burden for devices using synaptics-rmi4 transport drivers.

How an attack unfolds

An attacker with local access triggers system power management events such as suspend or resume on a system where the rmi_dev binding failed, causing the transport driver to invoke the functions on an unbound device and dereference NULL driver data.

How to fix it

Update to a Linux kernel containing the referenced fix that adds an early return when driver data is absent in the suspend and resume paths.

How to confirm the fix worked

Confirm the presence of the driver-data check before the mutex operations in rmi_driver_suspend and rmi_driver_resume after applying the kernel update; test suspend/resume cycles on systems with intentional bind failures.

Typical attack path

  1. Cause or wait for rmi_dev probe or bind failure
  2. Trigger system suspend or resume event
  3. Transport driver calls rmi_driver_suspend/resume on unbound device
  4. NULL dereference occurs inside IRQ enable/disable leading to GPF

How to detect it

Review kernel logs and crash dumps for General Protection Faults originating from rmi_driver_suspend, rmi_driver_resume, or rmi_disable_irq paths; correlate with device probe failure messages for rmi_dev.

What your security team should do

  • Prioritize kernel updates on systems using synaptics-rmi4 I2C or SPI transports
  • Monitor kernel logs for GPFs referencing rmi_driver_suspend or rmi_disable_irq
  • Apply the fix during the next maintenance window given the 17-day publication age

The record

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.

Affected packages

Ecosystem Package Introduced Fixed