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

exploitDog

fstec логотип

BDU:2024-09030

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

Описание

Уязвимость функции scsi_host_busy() компонента drivers/scsi/scsi_error.c ядра операционной системы Linux связана с восстановлением в памяти недостоверных данных. Эксплуатация уязвимости может позволить нарушителю вызвать отказ в обслуживании

Вендор

Сообщество свободного программного обеспечения
ООО «РусБИТех-Астра»
АО "НППКТ"

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

Debian GNU/Linux
Astra Linux Special Edition
Astra Linux Common Edition
Linux
ОСОН ОСнова Оnyx

Версия ПО

11 (Debian GNU/Linux)
12 (Debian GNU/Linux)
4.7 (Astra Linux Special Edition)
1.6 «Смоленск» (Astra Linux Common Edition)
от 5.5 до 5.10.209 включительно (Linux)
от 5.11 до 5.15.148 включительно (Linux)
от 5.16 до 6.1.76 включительно (Linux)
от 6.2 до 6.6.15 включительно (Linux)
до 2.10.1 (ОСОН ОСнова Оnyx)
от 6.7 до 6.7.3 включительно (Linux)

Тип ПО

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

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

Сообщество свободного программного обеспечения Debian GNU/Linux 11
Сообщество свободного программного обеспечения Debian GNU/Linux 12
ООО «РусБИТех-Астра» Astra Linux Special Edition 4.7
ООО «РусБИТех-Астра» Astra Linux Common Edition 1.6 «Смоленск»
Сообщество свободного программного обеспечения Linux до 5.10.210
АО "НППКТ" ОСОН ОСнова Оnyx до 2.10.1
Сообщество свободного программного обеспечения Linux от 5.11 до 5.15.149
Сообщество свободного программного обеспечения Linux от 6.0 до 6.1.77
Сообщество свободного программного обеспечения Linux от 6.2 до 6.6.16
Сообщество свободного программного обеспечения Linux от 6.7 до 6.7.4
Сообщество свободного программного обеспечения Linux от 6.8 до 6.8 rc3

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

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

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

Для Linux:
использование рекомендаций производителя: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4373534a9850627a2695317944898eb1283a2db0
Для Debian:
использование рекомендаций производителя: https://security-tracker.debian.org/tracker/CVE-2024-26627
Для ОС Astra Linux:
- обновить пакет linux-5.10 до 5.10.216-1.astra2+ci3 или более высокой версии, используя рекомендации производителя: https://wiki.astralinux.ru/astra-linux-se16-bulletin-20241017SE16
- обновить пакет linux-5.15 до 5.15.0-111.astra2+ci2 или более высокой версии, используя рекомендации производителя: https://wiki.astralinux.ru/astra-linux-se16-bulletin-20241017SE16
Для ОС Astra Linux Special Edition 4.7:
использование рекомендаций производителя: https://wiki.astralinux.ru/astra-linux-se47-bulletin-2024-1031SE47
Обновление программного обеспечения linux до версии 6.6.27-0.osnova229

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

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

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

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

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

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

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

EPSS

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

5.5 Medium

CVSS3

4.6 Medium

CVSS2

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

CVSS3: 5.5
ubuntu
больше 1 года назад

In the Linux kernel, the following vulnerability has been resolved: scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in-flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling scsi_host_busy() outside the host lock. We don't need the host lock ...

CVSS3: 5.5
redhat
больше 1 года назад

In the Linux kernel, the following vulnerability has been resolved: scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in-flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling scsi_host_busy() outside the host lock. We don't need the host lock ...

CVSS3: 5.5
nvd
больше 1 года назад

In the Linux kernel, the following vulnerability has been resolved: scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in-flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling scsi_host_busy() outside the host lock. We don't need the h

CVSS3: 5.5
debian
больше 1 года назад

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

CVSS3: 5.5
github
больше 1 года назад

In the Linux kernel, the following vulnerability has been resolved: scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in-flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling scsi_host_busy() outside the host lock. We don't need th...

EPSS

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

5.5 Medium

CVSS3

4.6 Medium

CVSS2