CVE-2026-98202

Executive Summary

CVE-2026-98202 is a NULL pointer dereference in the Linux kernel "Input: synaptics-rmi4" subsystem affecting the RMI4 driver used for Synaptics touchpad and touchscreen hardware. Transport drivers (rmi_i2c and rmi_spi) call rmi_driver_suspend() and rmi_driver_resume() on a child rmi_dev even when the physical RMI driver failed to bind or probe, and the missing driver-data check causes a General Protection Fault when locking data->enabled_mutex. The impact is limited to availability: a local denial of service and potential system instability triggered during system power management (suspend/resume) events, most likely in virtualized or misconfigured hardware environments where the RMI device is enumerated but not bound. No public exploit, no PoC, and no CISA KEV listing exist.

Technical Analysis

The Synaptics RMI4 (RMI4 = "Register Map Interface") subsystem in the Linux kernel splits functionality between a transport layer and a core/physical driver. Transport drivers such as rmi_i2c and rmi_spi manage the physical bus (I2C or SPI), while the rmi_dev child device is bound to the actual RMI driver that implements the touch protocol.

Per the NVD description, the defect arises from a lifecycle mismatch:

1. Transport drivers (rmi_i2c, rmi_spi) fully register and remain operational even if the physical RMI driver never successfully binds to or probes the rmi_dev device.
2. During system power management events, transport drivers invoke rmi_driver_suspend() and rmi_driver_resume() on their child rmi_dev device.
3. When invoked against an unbound rmi_dev, dev_get_drvdata() returns NULL — no driver data is attached.
4. rmi_driver_suspend() / rmi_driver_resume() proceed to call rmi_disable_irq() / rmi_enable_irq() respectively, which attempt to lock data->enabled_mutex on a NULL data pointer.
5. Dereferencing the NULL data pointer to lock the mutex results in a NULL pointer dereference, which on modern x86-64 with supervisor-mode SMAP/SMEP protections and non-canonical low addresses manifests as a General Protection Fault (GPF) — a kernel-level crash.

The fix, as described, adds an early-exit check in rmi_driver_suspend() and rmi_driver_resume() that verifies driver data is attached to rmi_dev before proceeding. This is a classic defensive-programming pattern for suspend/resume callbacks.

Vulnerability class: NULL pointer dereference (CWE-476) in kernel PM callbacks. Attack surface: local, requires a system state transition (suspend/resume) with an unbound RMI device present. This is not a memory corruption that can be leveraged for code execution — it is a crash/instability condition. The absence of a CVSS vector in the supplied data and the crash-only nature suggest a low-to-moderate severity profile, but the NVD assigns no score, so no authoritative severity is attached.

Insufficient technical detail is available regarding the exact affected kernel versions, the specific commit hash, and whether backports have been issued to stable/LTS branches. The description references only the function names rmi_driver_suspend(), rmi_driver_resume(), rmi_disable_irq(), rmi_enable_irq(), dev_get_drvdata(), and the field data->enabled_mutex — all of which are quoted verbatim from the source text and should not be extrapolated beyond that.

Exploitation Scenarios

No public proof-of-concept exists. The following attack chain is inferred strictly from the vulnerability class (kernel NULL pointer dereference in a PM callback) and the specifics stated in the NVD description. No code patterns or additional symbol names are invented.

1. Reconnaissance / target identification. An attacker with local access to a Linux system (e.g., a VM guest, a compromised container with limited privilege, or a user on a laptop) determines whether the system exposes a Synaptics RMI4 device (touchpad/touchscreen). This is typically enumerated via device tree or ACPI and visible in kernel logs and /sys entries for the rmi4 subsystem. The attacker identifies a state in which the physical RMI driver failed to bind the rmi_dev — a condition that can occur after driver load failures, module unload, or in virtualized environments where the emulated/repassed device is partially configured.

2. Triggering the flaw class. With the RMI device enumerated but the driver unbound, the attacker induces a system power management transition (suspend and/or resume). When the transport driver (rmi_i2c or rmi_spi) invokes rmi_driver_suspend() or rmi_driver_resume() on the unbound rmi_dev, dev_get_drvdata() returns NULL, and the subsequent attempt to lock data->enabled_mutex dereferences NULL, producing a General Protection Fault.

3. Payload / execution method. There is no payload in the conventional sense. The "trigger" is the suspend/resume state transition itself; no crafted input buffer, malformed packet, or code injection is required, because the vulnerable code path is reached through normal PM lifecycle events. An attacker who controls the ability to initiate suspend/resume (or who waits for an automatic transition) can therefore cause the crash without any crafted data. No public PoC available; attack chain is inferred from vulnerability class.

4. Post-exploitation impact. The impact is confined to a kernel crash / denial of service — loss of responsiveness, potential forced reboot, and disruption of any workloads in progress. Because this is a NULL dereference and not a controllable memory-corruption primitive, there is no documented path to privilege escalation or code execution from this CVE in the supplied data. Any escalation would require combining this with an unrelated second vulnerability, which is outside the scope of this report.

Impact Assessment

• Availability (primary): A General Protection Fault in a kernel PM callback crashes the kernel, resulting in system instability, unplanned reboots, or hang conditions during suspend/resume. This is a local denial-of-service condition.
• Confidentiality / Integrity: No evidence in the provided data that this flaw permits data disclosure or modification. The failure mode is a NULL dereference, which by itself does not yield arbitrary read/write.
• Attack vector / complexity: Local (requires presence on the system and a PM state transition with an unbound rmi_dev). Likely High attack complexity given the required precondition (unbound device + suspend/resume timing).
• Privileges required: On many systems, initiating suspend/resume requires elevated or specific session privileges (systemd/logind), though automatic PM transitions can occur without direct attacker action.
• Blast radius: Systems with Synaptics RMI4-based input hardware, particularly laptops, 2-in-1 convertibles, tablets, and virtualized/repassed environments where device binding is unreliable. Servers and headless systems without RMI4 hardware are not affected.
• CVSS: No score or vector supplied by the source (NVD = N/A). No EPSS score available (not yet scored by FIRST.org). CISA KEV: No. No weaponized exploit or in-the-wild activity is documented in the supplied data.

Detection Guidance

The following rules are best-effort detections for the vulnerability class (kernel NULL pointer dereference / GPF in the rmi4 PM path and related crash telemetry). Because this is a kernel-internal flaw with no network protocol component, network-layer detection is limited and the Suricata rule below is a heuristic/low-fidelity aid only.

Sigma Rule

title: Linux Kernel NULL Pointer Dereference in synaptics-rmi4 Suspend/Resume
id: 8f3c1a2e-rmi4-2026-null-deref
status: experimental
description: Detects kernel General Protection Fault / NULL pointer dereference originating from the synaptics-rmi4 driver suspend or resume callbacks.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-98202
author: valtersit.com
date: 2026/01/01
logsource:
  product: linux
  service: kernel
detection:
  keywords_gpf:
    - 'general protection fault'
    - 'GPF'
  keywords_rmi:
    - 'rmi_driver_suspend'
    - 'rmi_driver_resume'
    - 'synaptics-rmi4'
    - 'rmi4'
  keywords_null:
    - 'NULL pointer dereference'
    - 'enabled_mutex'
  condition: keywords_gpf and keywords_rmi
  # optional stricter variant:
  # condition: keywords_rmi and (keywords_gpf or keywords_null)
fields:
  - hostname
  - message
falsepositives:
  - Unrelated kernel panics in the input subsystem
  - Benign suspend/resume test harnesses
level: medium

YARA Rule

rule CVE_2026_98202_Linux_RMI4_NULL_DEREF
{
    meta:
        author = "valtersit.com"
        description = "Heuristic detection of rmi4 suspend/resume NULL deref crash strings in kernel logs or vmcore dumps"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-98202"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $rmi_suspend = "rmi_driver_suspend" ascii wide
        $rmi_resume  = "rmi_driver_resume" ascii wide
        $mutex       = "enabled_mutex" ascii wide
        $gpf         = "general protection fault" ascii nocase
        $nullderef   = "NULL pointer dereference" ascii nocase
        $synaptics   = "synaptics-rmi4" ascii
        $disableirq  = "rmi_disable_irq" ascii
        $enableirq   = "rmi_enable_irq" ascii

    condition:
        uint32(0) == 0x464c457f or  // match against ELF/vmlinux and dumps
        (
            ($rmi_suspend or $rmi_resume or $disableirq or $enableirq) and
            ($mutex or $gpf or $nullderef or $synaptics)
        )
}

Suricata IDS Rule

alert tcp any any -> any any (msg:"CVE-2026-98202 Heuristic - Linux rmi4 suspend/resume crash telemetry in forwarded logs"; flow:to_server,established; content:"rmi_driver_"; nocase; content:"general protection fault"; nocase; distance:0; within:2048; classtype:attempted-dos; sid:202698202; rev:1; metadata:created_at 2026_01_01, reference:nvd,nvd.nist.gov/vuln/detail/CVE-2026-98202;)
# NOTE: Low-fidelity heuristic only. This CVE has no network attack surface; the rule
# triggers on forwarded kernel log telemetry, not on an exploit payload.

Elastic Detection

// Detects kernel GPF / NULL pointer dereference tied to the synaptics-rmi4 PM path.
// Assumes kernel logs are ingested into Elasticsearch as process/event logs.
process where
  process.name in ("kernel", "dmesg") and
  (
    (message like~ "*rmi_driver_suspend*" or message like~ "*rmi_driver_resume*") and
    (
      message like~ "*general protection fault*" or
      message like~ "*NULL pointer dereference*" or
      message like~ "*enabled_mutex*"
    )
  )

Splunk SPL Query

index=os_linux sourcetype=kernel OR sourcetype=syslog
| search ("rmi_driver_suspend" OR "rmi_driver_resume" OR "synaptics-rmi4")
    AND ("general protection fault" OR "NULL pointer dereference" OR "enabled_mutex")
| stats count min(_time) as first_seen max(_time) as last_seen
    values(host) as hosts values(hostname) as hostnames
    by message
| eval first_seen=strftime(first_seen,"%Y-%m-%dT%H:%M:%S"),
       last_seen=strftime(last_seen,"%Y-%m-%dT%H:%M:%S")
| sort - count

Wazuh OSSEC Rule

<group name="linux,kernel,cve-2026-98202,">
  <rule id="100982020" level="10" frequency="1" timeframe="600">
    <decoded_as>kernel-syslog</decoded_as>
    <match>general protection fault</match>
    <description>CVE-2026-98202: Linux kernel General Protection Fault possible rmi4 suspend/resume NULL deref</description>
    <mitre>
      <id>T1499</id>
    </mitre>
    <group>kernel_crash,</group>
  </rule>

  <rule id="100982021" level="8" frequency="1" timeframe="600">
    <decoded_as>kernel-syslog</decoded_as>
    <match>rmi_driver_suspend|rmi_driver_resume|enabled_mutex</match>
    <description>CVE-2026-98202: rmi4 suspend/resume callback activity on unbound device</description>
    <mitre>
      <id>T1499</id>
    </mitre>
    <group>kernel_crash,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, no workaround, no affected version list, and no OSV package data were provided in the supplied intelligence. The only fix referenced is the upstream Linux kernel commit described in the NVD text, for which no hash or stable-branch backport is confirmed here.

1. Immediate mitigations (compensating controls)

   • Avoid unnecessary system suspend/resume cycles on affected hardware until a patched kernel is confirmed; where suspend is not operationally required, disable it on managed endpoints via power-management policy.
   • On virtualized and re-passed-hypervisor environments, avoid exposing or partially configuring Synaptics RMI4 input devices where the physical driver may fail to bind. Prefer configurations where the device is cleanly bound or fully absent.
   • Restrict local interactive access to systems with RMI4 hardware (least-privilege, disable autologin, enforce session locks) to reduce the population of users who can trigger a PM transition.
   • Monitor kernel logs for General Protection Faults originating in the input/rmi4 subsystem to detect both accidental and deliberate triggers.

2. Patch / upgrade steps

   • Apply the upstream Linux kernel fix that adds an early-exit when driver data is absent in rmi_driver_suspend() and rmi_driver_resume(), as described in the CVE. Confirm the fix has landed in the specific kernel branch in use before relying on it.
   • Track stable/LTS backports for the affected kernels deployed in your fleet. No backport confirmation is available in the supplied data, so verify against your distribution's kernel advisory feed.
   • Validate the fix by reproducing the suspend/resume cycle on a test system where the rmi_dev driver is unbound and confirming no GPF occurs.
   • Because patch confidence is 0/4, treat any third-party "patch" claim as unverified until corroborated by the upstream changelog and your distribution vendor.

3. Long-term hardening

   • Maintain a hardware/driver inventory for input devices, and explicitly test suspend/resume stability as part of hardware qualification for laptops, tablets, and 2-in-1s.
   • Adopt kernel hardening options that reduce the impact of stray PM callbacks (e.g., keep kernel symbol and console logging enabled so crashes are attributed rather than silently rebooting).
   • Operationalize crash telemetry: forward kernel logs to the SIEM and alert on GPF/NULL-deref events tied to driver subsystem names.
   • Integrate kernel CVE triage into your patch management lifecycle so that N/A-severity CVEs with local-DoS preconditions are still tracked and validated, not dropped solely because no CVSS score exists.

References

• NVD — CVE-2026-98202: https://nvd.nist.gov/vuln/detail/CVE-2026-98202
• Linux kernel source tree, drivers/input/rmi4/ — the rmi_driver_suspend() and rmi_driver_resume() PM callbacks referenced in the CVE description: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/input/rmi4
• Linux kernel input subsystem documentation (RMI4): https://docs.kernel.org/input/
• FIRST.org EPSS (no score currently available for this CVE): https://www.first.org/epss/
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-98202 is NOT listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Threat actor / exploit-in-the-wild status: none documented in available data; no CISA KEV entry, no public PoC, no Nuclei template, no observed exploitation.