Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

fstec логотип

BDU:2024-09196

Опубликовано: 28 фев. 2024
Источник: fstec
CVSS3: 5.5
CVSS2: 4.6
EPSS Низкий

Описание

Уязвимость компонента perf ядра операционной системы Linux связана с разыменованием указателя NULL в функции stmmac_fpe_stop_wq(). Эксплуатация уязвимости может позволить нарушителю вызвать отказ в обслуживании

Вендор

Red Hat Inc.
Сообщество свободного программного обеспечения
ООО «Ред Софт»
АО "НППКТ"

Наименование ПО

Red Hat Enterprise Linux
Debian GNU/Linux
РЕД ОС
Linux
ОСОН ОСнова Оnyx

Версия ПО

8 (Red Hat Enterprise Linux)
12 (Debian GNU/Linux)
7.3 (РЕД ОС)
от 5.16 до 6.1.80 включительно (Linux)
от 6.2 до 6.6.20 включительно (Linux)
до 2.10.1 (ОСОН ОСнова Оnyx)
от 6.7 до 6.7.8 включительно (Linux)
от 5.13 до 5.15.150 включительно (Linux)

Тип ПО

Операционная система

Операционные системы и аппаратные платформы

Red Hat Inc. Red Hat Enterprise Linux 8
Сообщество свободного программного обеспечения Debian GNU/Linux 12
ООО «Ред Софт» РЕД ОС 7.3
АО "НППКТ" ОСОН ОСнова Оnyx до 2.10.1
Сообщество свободного программного обеспечения Linux 6.8 rc1
Сообщество свободного программного обеспечения Linux от 6.1 до 6.1.81
Сообщество свободного программного обеспечения Linux от 6.6 до 6.6.21
Сообщество свободного программного обеспечения Linux от 6.7 до 6.7.9
Сообщество свободного программного обеспечения Linux от 5.13 до 5.15.151

Уровень опасности уязвимости

Средний уровень опасности (базовая оценка CVSS 2.0 составляет 4,6)
Средний уровень опасности (базовая оценка CVSS 3.0 составляет 5,5)
Нет опасности уровень опасности (базовая оценка CVSS 4.0 составляет 0)

Возможные меры по устранению уязвимости

В условиях отсутствия обновлений безопасности от производителя рекомендуется придерживаться "Рекомендаций по безопасной настройке операционных систем LINUX", изложенных в методическом документе ФСТЭК России, утверждённом 25 декабря 2022 года.
Использование рекомендаций:
Для Linux:
https://lore.kernel.org/linux-cve-announce/2024040403-CVE-2024-26802-b3da@gregkh/T/#u
Для РедОС:
http://repo.red-soft.ru/redos/7.3c/x86_64/updates/
Для Debian GNU/Linux:
https://security-tracker.debian.org/tracker/CVE-2024-26802
Для программных продуктов Red Hat Inc.:
https://access.redhat.com/security/cve/CVE-2024-26802
Обновление программного обеспечения linux до версии 6.6.27-0.osnova229

Статус уязвимости

Подтверждена производителем

Наличие эксплойта

Данные уточняются

Информация об устранении

Уязвимость устранена

Идентификаторы других систем описаний уязвимостей

EPSS

Процентиль: 1%
0.00009
Низкий

5.5 Medium

CVSS3

4.6 Medium

CVSS2

Связанные уязвимости

ubuntu
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: stmmac: Clear variable when destroying workqueue Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped...

CVSS3: 5.5
redhat
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: stmmac: Clear variable when destroying workqueue Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped...

nvd
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: stmmac: Clear variable when destroying workqueue Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skipped

debian
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: s ...

github
около 1 года назад

In the Linux kernel, the following vulnerability has been resolved: stmmac: Clear variable when destroying workqueue Currently when suspending driver and stopping workqueue it is checked whether workqueue is not NULL and if so, it is destroyed. Function destroy_workqueue() does drain queue and does clear variable, but it does not set workqueue variable to NULL. This can cause kernel/module panic if code attempts to clear workqueue that was not initialized. This scenario is possible when resuming suspended driver in stmmac_resume(), because there is no handling for failed stmmac_hw_setup(), which can fail and return if DMA engine has failed to initialize, and workqueue is initialized after DMA engine. Should DMA engine fail to initialize, resume will proceed normally, but interface won't work and TX queue will eventually timeout, causing 'Reset adapter' error. This then does destroy workqueue during reset process. And since workqueue is initialized after DMA engine and can be skip...

EPSS

Процентиль: 1%
0.00009
Низкий

5.5 Medium

CVSS3

4.6 Medium

CVSS2