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

exploitDog

fstec логотип

BDU:2025-09190

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

Описание

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

Вендор

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

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

Red Hat Enterprise Linux
Debian GNU/Linux
Linux

Версия ПО

8 (Red Hat Enterprise Linux)
11 (Debian GNU/Linux)
12 (Debian GNU/Linux)
9 (Red Hat Enterprise Linux)
10 (Red Hat Enterprise Linux)
до 6.16 rc6 (Linux)
от 4.18 до 5.4.296 (Linux)
от 4.18 до 5.10.240 (Linux)
от 4.18 до 5.15.189 (Linux)
от 4.18 до 6.1.146 (Linux)
от 4.18 до 6.12.39 (Linux)
от 4.18 до 6.15.7 (Linux)
от 4.18 до 6.6.99 (Linux)

Тип ПО

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

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

Red Hat Inc. Red Hat Enterprise Linux 8
Сообщество свободного программного обеспечения Debian GNU/Linux 11
Сообщество свободного программного обеспечения Debian GNU/Linux 12
Red Hat Inc. Red Hat Enterprise Linux 9
Red Hat Inc. Red Hat Enterprise Linux 10
Сообщество свободного программного обеспечения Linux до 6.16 rc6
Сообщество свободного программного обеспечения Linux от 4.18 до 5.4.296
Сообщество свободного программного обеспечения Linux от 4.18 до 5.10.240
Сообщество свободного программного обеспечения Linux от 4.18 до 5.15.189
Сообщество свободного программного обеспечения Linux от 4.18 до 6.1.146
Сообщество свободного программного обеспечения Linux от 4.18 до 6.12.39
Сообщество свободного программного обеспечения Linux от 4.18 до 6.15.7
Сообщество свободного программного обеспечения Linux от 4.18 до 6.6.99

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

Средний уровень опасности (базовая оценка CVSS 2.0 составляет 6)
Высокий уровень опасности (базовая оценка CVSS 3.1 составляет 7)

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

В условиях отсутствия обновлений безопасности от производителя рекомендуется придерживаться "Рекомендаций по безопасной настройке операционных систем LINUX", изложенных в методическом документе ФСТЭК России, утверждённом 25 декабря 2022 года.
Использование рекомендаций:
Для Linux:
https://lore.kernel.org/linux-cve-announce/2025072503-CVE-2025-38445-7295@gregkh/
Для программных продуктов Red Hat Inc.:
https://access.redhat.com/security/cve/cve-2025-38445
Для Debian GNU/Linux:
https://security-tracker.debian.org/tracker/CVE-2025-38445

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

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

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

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

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

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

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

EPSS

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

7 High

CVSS3

6 Medium

CVSS2

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

ubuntu
12 дней назад

In the Linux kernel, the following vulnerability has been resolved: md/raid1: Fix stack memory use after return in raid1_reshape In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic. Example access path: raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool; } raid1_read_request() or raid1_write_request() { alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } } } mempool_free() { if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } } Fix: reinit conf->r1bio_pool.wait after assigning newpool.

CVSS3: 7
redhat
12 дней назад

In the Linux kernel, the following vulnerability has been resolved: md/raid1: Fix stack memory use after return in raid1_reshape In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic. Example access path: raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool; } raid1_read_request() or raid1_write_request() { alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } } } mempool_free() { if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } } Fix: reinit conf->r1bio_pool.wait after assigning newpool.

nvd
12 дней назад

In the Linux kernel, the following vulnerability has been resolved: md/raid1: Fix stack memory use after return in raid1_reshape In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic. Example access path: raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool; } raid1_read_request() or raid1_write_request() { alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } } } mempool_free() { if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } } Fix: reinit conf->r1bio_pool.wa

debian
12 дней назад

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

github
12 дней назад

In the Linux kernel, the following vulnerability has been resolved: md/raid1: Fix stack memory use after return in raid1_reshape In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic. Example access path: raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool; } raid1_read_request() or raid1_write_request() { alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } } } mempool_free() { if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } } Fix: reinit conf->r1bio_pool...

EPSS

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

7 High

CVSS3

6 Medium

CVSS2