CVE-2026-72124 in Linux
Сводка
по VulDB • 16.08.2026
В ядре Linux устранена следующая уязвимость:
can: isotp: сериализация переходов состояния TX под блокировкой so->rx_lock
Машина состояний передачи (so->tx.state) управляется из трех контекстов: sendmsg(), захватывающая и продвигающая передачу; путь приема, потребляющий кадры управления потоком/эха; и два таймера hrtimer, отслеживающие зависшую передачу. Использование lock-free cmpxchg() для захвата в sendmsg() совместно с вызовами hrtimer_cancel(), выполняемыми под so->rx_lock в других местах, оставляло окна возможностей, когда обратный вызов кадра или таймера мог воздействовать на состояние, которое уже изменилось, что приводило к повреждению unrelated (не связанной) передачи.
Теперь so->rx_lock охватывает полный жизненный цикл захвата TX: sendmsg() получает ее для проверки того, что so->tx.state равен ISOTP_IDLE, переключает его в ISOTP_SENDING, увеличивает so->tx_gen и очищает таймеры предыдущей передачи — все это как один критический раздел. isotp_rcv_fc()/isotp_rcv_cf() уже выполняются под этой блокировкой через isotp_rcv(), а isotp_rcv_echo() теперь получает ее самостоятельно, поэтому ни одна из них не может наблюдать передачу в процессе захвата. Это также означает, что передача больше не может быть передана путям очистки sendmsg()'а (сигнал или отправка ошибки), пока другой поток одновременно выполняет захват или завершение этой передачи; таким образом, эти пути могут безопасно отменять таймеры и сбрасывать состояние без дополнительных проверок.
isotp_release() захватывает сокет аналогичным образом, поэтому конкурирующий sendmsg() видит согласованное ISOTP_SHUTDOWN и пропускает установку своего таймера или отправку данных.
Только обратные вызовы hrtimer остаются вне so->rx_lock, поскольку они выполняются в контексте отмены под so->rx_lock в других местах, а их самостоятельное получение блокировки привело бы к взаимной блокировке (deadlock). Переменная so->tx_gen позволяет им распознавать, является ли таймаутнутая передача все еще активной на данный момент, поэтому они не сообщают об ошибке для передачи, которая уже завершилась или была заменена.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.