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

exploitDog

fstec логотип

BDU:2025-00803

Опубликовано: 21 мар. 2021
Источник: fstec
CVSS3: 5.5
CVSS2: 4.6
EPSS Низкий

Описание

Уязвимость компонента drivers/nvme/target/tcp.c ядра операционной системы Linux связана с недостаточной блокировкой. Эксплуатация уязвимости может позволить нарушителю вызвать отказ в обслуживании

Вендор

Canonical Ltd.
Red Hat Inc.
ООО «РусБИТех-Астра»
Сообщество свободного программного обеспечения

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

Ubuntu
Red Hat Enterprise Linux
Astra Linux Special Edition для «Эльбрус»
Linux
Debian GNU/Linux

Версия ПО

18.04 LTS (Ubuntu)
8 (Red Hat Enterprise Linux)
8.1 «Ленинград» (Astra Linux Special Edition для «Эльбрус»)
20.04 LTS (Ubuntu)
от 5.11 до 5.11.21 (Linux)
от 5.12 до 5.12.4 (Linux)
до 5.13 (Linux)
11 (Debian GNU/Linux)
12 (Debian GNU/Linux)
9 (Red Hat Enterprise Linux)
от 5.5 до 5.10.37 (Linux)
от 5.0 до 5.4.119 (Linux)

Тип ПО

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

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

Canonical Ltd. Ubuntu 18.04 LTS
Red Hat Inc. Red Hat Enterprise Linux 8
ООО «РусБИТех-Астра» Astra Linux Special Edition для «Эльбрус» 8.1 «Ленинград»
Canonical Ltd. Ubuntu 20.04 LTS
Сообщество свободного программного обеспечения Linux от 5.11 до 5.11.21
Сообщество свободного программного обеспечения Linux от 5.12 до 5.12.4
Сообщество свободного программного обеспечения Linux до 5.13
Сообщество свободного программного обеспечения Debian GNU/Linux 11
Сообщество свободного программного обеспечения Debian GNU/Linux 12
Red Hat Inc. Red Hat Enterprise Linux 9
Сообщество свободного программного обеспечения Linux от 5.5 до 5.10.37
Сообщество свободного программного обеспечения Linux от 5.0 до 5.4.119

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

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

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

В условиях отсутствия обновлений безопасности от производителя рекомендуется придерживаться "Рекомендаций по безопасной настройке операционных систем LINUX", изложенных в методическом документе ФСТЭК России, утверждённом 25 декабря 2022 года.
Использование рекомендаций:
Для Linux:
https://lore.kernel.org/linux-cve-announce/2024022838-CVE-2021-47041-de92@gregkh/
Для Debian GNU/Linux:
https://security-tracker.debian.org/tracker/CVE-2021-47041
Для Ubuntu:
https://ubuntu.com/security/CVE-2021-47041
Для программных продуктов Red Hat Inc.:
https://access.redhat.com/security/cve/CVE-2021-47041
Для ОС Astra Linux:
https://wiki.astralinux.ru/astra-linux-se81-bulletin-20241206SE81

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

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

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

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

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

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

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

EPSS

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

5.5 Medium

CVSS3

4.6 Medium

CVSS2

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

CVSS3: 5.5
ubuntu
почти 2 года назад

In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0...

CVSS3: 4.4
redhat
почти 2 года назад

In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0...

CVSS3: 5.5
nvd
почти 2 года назад

In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_

CVSS3: 5.5
debian
почти 2 года назад

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

CVSS3: 5.5
github
почти 2 года назад

In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_da...

EPSS

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

5.5 Medium

CVSS3

4.6 Medium

CVSS2