Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound

drivers/input/rmi4/rmi_driver.c int rmi_driver_suspend(struct rmi_device *rmi_dev, bool enable_wake) · line 1003

[Severity: Medium]
This isn't a bug introduced by this patch, but looking at the rest of rmi_driver_suspend():

rmi_driver_suspend() {
    ...
    retval = rmi_suspend_functions(rmi_dev);
    if (retval)
        dev_warn(&rmi_dev->dev, "Failed to suspend functions: %d\n", retval);
    
    rmi_disable_irq(rmi_dev, enable_wake);
    return retval;
}

If rmi_suspend_functions() fails, the error path still disables the IRQ and returns the error to the PM core. The I2C transport driver then unconditionally disables regulators in rmi_i2c_suspend() and also propagates the error.

Since the PM core aborts suspend and skips calling resume for devices that return an error, does this leave the device permanently disabled and unresponsive?

drivers/input/rmi4/rmi_driver.c int rmi_driver_resume(struct rmi_device *rmi_dev, bool clear_wake) · line 1023

[Severity: Low]
This is a pre-existing issue, but further down in rmi_driver_resume() there appears to be a copy-paste error in the warning message:

rmi_driver_resume() {
    ...
    retval = rmi_resume_functions(rmi_dev);
    if (retval)
        dev_warn(&rmi_dev->dev, "Failed to suspend functions: %d\n",
            retval);
    ...
}

Should this warning say "Failed to resume functions"? Similarly, in rmi_i2c_suspend(), there is a warning that says "Failed to resume device" when suspend fails.

[Severity: High]
This is a pre-existing issue, but since this patch addresses NULL pointer dereferences from unbound devices, is there a similar vulnerability in rmi_set_attn_data()?

rmi_set_attn_data() {
    struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev);
    
    if (!drvdata->enabled)
        return;
    ...
}

If rmi_driver_probe() fails, dev_get_drvdata() is cleared to NULL. However, the HID transport driver (hid-rmi) sets the RMI_STARTED bit after successful transport registration, independent of the physical driver probe.

If hardware sends events or malicious data is provided after a probe failure, can rmi_input_event() bypass the RMI_STARTED check and call rmi_set_attn_data(), leading to a NULL pointer dereference when accessing drvdata->enabled?

[Severity: High]
This is another pre-existing issue, but looking at the error handling in rmi_driver_probe():

rmi_driver_probe() {
    ...
    err_destroy_functions:
        rmi_free_function_list(rmi_dev);
    err:
        return retval;
}

If rmi_driver_probe() fails after successfully calling rmi_f34_create_sysfs(), it jumps to err_destroy_functions but misses a call to rmi_f34_remove_sysfs().

Does this leak the sysfs group? If the sysfs group is leaked and the driver core clears drvdata, could a later user-space read to the world-readable update_fw_status sysfs attribute trigger a NULL pointer dereference in rmi_driver_update_fw_status_show() when it checks data->f34_container?

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1