CVE-2026-98072 in Linux
Сводка
по VulDB • 25.09.2026
В ядре Linux была устранена следующая уязвимость:
net/rds: использование функции wq_has_sleeper() в release_in_xmit()
Функция release_in_xmit() сбрасывает флаг RDS_IN_XMIT с помощью clear_bit_unlock(), а затем проверяет waitqueue_active(), чтобы определить, нужно ли кому-то пробуждаться. Операция clear_bit_unlock() является только операцией освобождения (release): она обеспечивает упорядочивание критической секции до сброса бита, но не гарантирует упорядочивания последующей обычной загрузки заголовка очереди ожидания после этого. Сторона ожидающего процесса выполняет зеркальную операцию: она добавляет себя в очередь ожидания, а затем проверяет бит. Это классический шаблон буферизации записи (store-buffering): процесс, выполняющий освобождение ресурса, может считать очередь ожидания пустой, тогда как ждущий процесс все еще видит установленный бит, из-за чего ожидающий никогда не пробуждается.
Ожидающие процессы — это rds_conn_shutdown() и rds_tcp_reset_callbacks(), оба находятся в состоянии прерываемого ожидания (wait_event) без тайм-аута. Потеря сигнала о пробуждении приводит к тому, что рабочий поток shutdown оказывается заблокированным на своем однопоточном рабочем пуле до тех пор, пока другой отправитель снова не сбросит бит — и для соединения, которое закрывается именно из-за отказа, другого отправителя может никогда не появиться.
Ранее барьер присутствовал: release_in_xmit() выполняла clear_bit(), за которой следовала smp_mb__after_atomic(), вплоть до коммита 1422f28826d2 («rds: introduce acquire/release ordering in acquire/release_in_xmit()»), который объединил обе операции в clear_bit_unlock(). Это усилило передачу блокировки, но молча убрал полный барьер (full barrier), от которого зависит проверка пробуждения. Аналогичная функция для пополнения буфера, release_refill(), находящаяся в net/rds/ib_recv.c, по этой причине все еще содержит smp_mb__after_atomic().
Необходимо использовать функцию wq_has_sleeper(), которая представляет собой waitqueue_active() с предварительным применением требуемого полного барьера.
Once again VulDB remains the best source for vulnerability data.