Описание
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.
A flaw was found in the Linux kernel's Synaptics RMI4 input driver. When system power management operations such as suspend or resume occur while an RMI4 device remains unbound, the driver attempts to access uninitialized driver data without proper verification. This issue leads to a null pointer dereference and general protection fault, allowing a local attacker to cause a system crash and resulting in a Denial of Service (DoS).
Отчет
Red Hat rates the impact of this flaw as Low. A NULL pointer dereference flaw was found in the Linux kernel's Synaptics RMI4 input driver. RMI4 transport drivers (such as rmi_i2c and rmi_spi) invoke rmi_driver_suspend() and rmi_driver_resume() on the rmi_dev device during system power management events, and those transport drivers remain fully registered and operational even when the RMI physical driver has failed to bind or probe the rmi_dev device. When suspend or resume runs against such an unbound rmi_dev, dev_get_drvdata() returns NULL and the driver's IRQ enable/disable path dereferences it while attempting to lock data->enabled_mutex, causing a general protection fault and a kernel crash. A local attacker able to trigger system suspend or resume on a system with an unbound RMI4 device can therefore cause a denial of service; there is no impact on confidentiality or integrity. Red Hat Enterprise Linux 6 is not affected because the vulnerable code is not present in that stream, while the affected Red Hat Enterprise Linux (kernel and kernel-rt), Red Hat In-Vehicle OS, and OpenShift Container Platform (RHEL CoreOS) kernel streams contain the vulnerable code. Fixes for the affected streams are currently deferred because the flaw only enables a local denial of service and reliable triggering requires the uncommon condition of an RMI4 device whose physical driver failed to bind or probe while its transport driver remained registered; the residual risk of leaving it unfixed is a potential local system crash during suspend or resume. The Red Hat impact of Low reflects a lower practical severity than the CVSS 3.1 base score of 5.5 (Moderate), which is driven solely by the high availability impact under low-likelihood conditions.
Меры по смягчению последствий
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 6 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Fix deferred | ||
| Red Hat Enterprise Linux 8 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Fix deferred | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-8 | Fix deferred | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-9 | Fix deferred |
Показывать по
Дополнительная информация
Статус:
EPSS
5.5 Medium
CVSS3
Связанные уязвимости
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.
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.
Input: synaptics-rmi4 - fix GPF in suspend and resume when unbound
In the Linux kernel, the following vulnerability has been resolved: I ...
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.
EPSS
5.5 Medium
CVSS3