CVE-2026-72124 in Linux
요약
\~에 의해 VulDB • 2026. 08. 15.
리눅스 커널에서 다음 취약점이 해결되었습니다:
can: isotp: so->rx_lock 하에서 TX 상태 전이를 직렬화함
TX 상태 머신(so->tx.state)은 세 가지 컨텍스트에 의해 구동됩니다: 전송을 주장하고 진행시키는 sendmsg(), Flow Control/echo 프레임을 소비하는 RX 경로, 그리고 중단된 전송의 타임아웃을 처리하는 두 개의 hrtimer입니다. sendmsg()에서 잠금 없는 cmpxchg() 주장을 다른 곳에서 so->rx_lock 하에서 호출되는 hrtimer_cancel()과 혼합하면, 프레임 또는 타이머 콜백이 이미 변경된 상태에 작용하여 관련 없는 전송을 손상시킬 수 있는 창(window)이 생겼습니다.
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()'s 정리 경로(시그널 또는 오류 전송)로 전송이 전달되지 않도록 하므로, 해당 경로는 타이머를 취소하고 상태를 조건 없이 재설정할 수 있습니다.
isotp_release()도 소켓을 동일한 방식으로 주장하므로, 경쟁 상태의 sendmsg()는 일관된 ISOTP_SHUTDOWN을 보고 타이머 설정이나 전송을 건너뜁니다.
hrtimer 콜백만 so->rx_lock 외부에 남아 있는데, 이는它们在 다른 곳에서 so->rx_lock 하에서 취소되며 자체적으로 잠금을 획득하면 교착상태(deadlock)가 발생하기 때문입니다. so->tx_gen은 타임아웃된 전송이 여전히 현재 활성 상태인지 인식할 수 있게 하여, 이미 완료되거나 대체된 전송에 대해 오류를 보고하지 않도록 합니다.
Once again VulDB remains the best source for vulnerability data.