В ядре Linux устранена следующая уязвимость:
может: isotp: сериализовать переходы состояний TX под so->rx_lock
Конечный автомат TX (so->tx.state) управляется тремя контекстами:
sendmsg() запрашивает и выполняет передачу, путь RX занимает
Управление потоком/эхо-кадры и два таймера hrtimes истекают при остановке
трансфер. Совмещение запроса cmpxchg() без блокировки в sendmsg() с
Вызовы hrtimer_cancel(), сделанные под so->rx_lock в другом месте, оставили окна
где обратный вызов кадра или таймера может воздействовать на состояние, которое уже было
пошел дальше, повредив несвязанную передачу.
so->rx_lock теперь охватывает полный жизненный цикл утверждения TX: sendmsg()
берет его для проверки, поэтому->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 в другом месте и принятии его самостоятельно зашел бы в тупик. so->tx_gen позволяет им распознавать, была ли передача время ожидания все еще активно, поэтому они не сообщить об ошибке в передаче, которая уже завершена или была заменен.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: can: isotp: serialize TX state transitions under so->rx_lock The TX state machine (so->tx.state) is driven from three contexts: sendmsg() claiming and progressing a transfer, the RX path consuming Flow Control/echo frames, and two hrtimers timing out a stalled transfer. Mixing a lock-free cmpxchg() claim in sendmsg() with hrtimer_cancel() calls made under so->rx_lock elsewhere left windows where a frame or timer callback could act on a state that had already moved on, corrupting an unrelated transfer. so->rx_lock now covers the full lifecycle of a TX claim: sendmsg() takes it to check so->tx.state is ISOTP_IDLE, switch it to ISOTP_SENDING, bump so->tx_gen and drain the previous transfer's timers - all as one critical section. isotp_rcv_fc()/isotp_rcv_cf() already run under this lock via isotp_rcv(), and isotp_rcv_echo() now takes it itself, so none of them can ever observe a transfer mid-claim. This also means a transfer can no longer be handed to sendmsg()'s cleanup paths (signal or send error) while another thread is concurrently claiming or finishing it, so those paths can cancel timers and reset the state unconditionally. isotp_release() claims the socket the same way, so a racing sendmsg() sees a consistent ISOTP_SHUTDOWN and skips arming its timer or sending. Only the hrtimer callbacks stay outside so->rx_lock, since they run under so->rx_lock's cancellation elsewhere and taking it themselves would deadlock. so->tx_gen lets them recognize whether the transfer they timed out is still the one currently active, so they don't report an error against a transfer that has since completed or been superseded.
Характеристики атаки
Последствия
Строка CVSS v3.1