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

exploitDog

fstec логотип

BDU:2025-13489

Опубликовано: 03 июл. 2025
Источник: fstec
CVSS3: 4.8
CVSS2: 4.3
EPSS Низкий

Описание

Уязвимость функции e1000_reset_task() ядра операционной системы Linux связана с зависанием. Эксплуатация уязвимости может позволить нарушителю, действующему удалённо, оказать воздействие на доступность защищаемой информации

Вендор

Сообщество свободного программного обеспечения

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

Linux

Версия ПО

от 6.13 до 6.15.3 (Linux)
до 6.16 rc2 (Linux)

Тип ПО

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

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

Сообщество свободного программного обеспечения Linux от 6.13 до 6.15.3
Сообщество свободного программного обеспечения Linux до 6.16 rc2

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

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

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

В условиях отсутствия обновлений безопасности от производителя рекомендуется придерживаться "Рекомендаций по безопасной настройке операционных систем LINUX", изложенных в методическом документе ФСТЭК России, утверждённом 25 декабря 2022 года.
Использование рекомендаций:
Для Linux:
https://lore.kernel.org/linux-cve-announce/2025070325-CVE-2025-38114-c603@gregkh/
https://git.kernel.org/stable/c/1fd4438ddcc4958ed24662d5125114299e19bae4
https://git.kernel.org/stable/c/b4a8085ceefb7bbb12c2b71c55e71fc946c6929f

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

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

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

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

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

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

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

EPSS

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

4.8 Medium

CVSS3

4.3 Medium

CVSS2

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

CVSS3: 5.5
ubuntu
6 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: e1000: Move cancel_work_sync to avoid deadlock Previously, e1000_down called cancel_work_sync for the e1000 reset task (via e1000_down_and_stop), which takes RTNL. As reported by users and syzbot, a deadlock is possible in the following scenario: CPU 0: - RTNL is held - e1000_close - e1000_down - cancel_work_sync (cancel / wait for e1000_reset_task()) CPU 1: - process_one_work - e1000_reset_task - take RTNL To remedy this, avoid calling cancel_work_sync from e1000_down (e1000_reset_task does nothing if the device is down anyway). Instead, call cancel_work_sync for e1000_reset_task when the device is being removed.

CVSS3: 7
redhat
6 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: e1000: Move cancel_work_sync to avoid deadlock Previously, e1000_down called cancel_work_sync for the e1000 reset task (via e1000_down_and_stop), which takes RTNL. As reported by users and syzbot, a deadlock is possible in the following scenario: CPU 0: - RTNL is held - e1000_close - e1000_down - cancel_work_sync (cancel / wait for e1000_reset_task()) CPU 1: - process_one_work - e1000_reset_task - take RTNL To remedy this, avoid calling cancel_work_sync from e1000_down (e1000_reset_task does nothing if the device is down anyway). Instead, call cancel_work_sync for e1000_reset_task when the device is being removed.

CVSS3: 5.5
nvd
6 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: e1000: Move cancel_work_sync to avoid deadlock Previously, e1000_down called cancel_work_sync for the e1000 reset task (via e1000_down_and_stop), which takes RTNL. As reported by users and syzbot, a deadlock is possible in the following scenario: CPU 0: - RTNL is held - e1000_close - e1000_down - cancel_work_sync (cancel / wait for e1000_reset_task()) CPU 1: - process_one_work - e1000_reset_task - take RTNL To remedy this, avoid calling cancel_work_sync from e1000_down (e1000_reset_task does nothing if the device is down anyway). Instead, call cancel_work_sync for e1000_reset_task when the device is being removed.

CVSS3: 5.5
debian
6 месяцев назад

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

CVSS3: 5.5
github
6 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: e1000: Move cancel_work_sync to avoid deadlock Previously, e1000_down called cancel_work_sync for the e1000 reset task (via e1000_down_and_stop), which takes RTNL. As reported by users and syzbot, a deadlock is possible in the following scenario: CPU 0: - RTNL is held - e1000_close - e1000_down - cancel_work_sync (cancel / wait for e1000_reset_task()) CPU 1: - process_one_work - e1000_reset_task - take RTNL To remedy this, avoid calling cancel_work_sync from e1000_down (e1000_reset_task does nothing if the device is down anyway). Instead, call cancel_work_sync for e1000_reset_task when the device is being removed.

EPSS

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

4.8 Medium

CVSS3

4.3 Medium

CVSS2

Уязвимость BDU:2025-13489