🇰🇷 한글 설명
Linux 커널의 SCTP 프로토콜 구현에서 데이터 청크의 전송 대상(transport) 정보가 실제 큐 위치와 일치하지 않아 발생하는 Use-After-Free 취약점입니다. ASCONF Delete-IP 작업으로 특정 전송 객체가 해제된 후, SACK 패킷이 처리되는 과정에서 이미 해제된 메모리 영역에 접근하여 시스템 오류를 유발할 수 있습니다.
💡 쉬운 설명
데이터를 주고받는 통로 정보가 실제와 다르게 기록되어, 이미 사라진 통로를 다시 사용하려고 시도할 때 발생하는 오류입니다. 이로 인해 시스템이 갑자기 멈추거나 보안 문제가 생길 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
sctp: keep chunk->transport in step with the list it is queued on
__sctp_outq_flush_rtx() moves a gap-acked chunk onto another transport's
transmitted list without updating chunk->transport:
if (chunk->tsn_gap_acked) {
list_move_tail(&chunk->transmitted_list,
&transport->transmitted);
continue;
}
The chunk then sits on a live transport's list while chunk->transport still
names a different one. If that transport is removed - sctp_assoc_rm_peer()
from an ASCONF Delete-IP - sctp_transport_free() RCU-frees it and the chunk
is left with a dangling pointer. sctp_assoc_rm_peer() scrubs
peer->transmitted and asoc->outqueue.out_chunk_list, but the chunk is on
neither.
The pointer is not followed while tsn_gap_acked is set. A SACK that
reneges on the TSN clears the flag, and the next SACK reaches
tchunk->transport->flight_size -= sctp_data_size(tchunk);
inside the freed transport. KASAN reports a slab-use-after-free read in
sctp_check_transmitted(), freed from sctp_assoc_rm_peer(). Both the
removal and the SACKs come from the association peer.
Set chunk->transport at the move. The ordinary resend path needs nothing:
it reaches its list_move_tail() only after sctp_packet_append_chunk()
returned SCTP_XMIT_OK, and __sctp_packet_append_chunk() has rebound the
chunk by then.
Discovered by XBOW, triaged by Baul Lee <
[email protected]>
📍 영향받는 시스템
SCTP 프로토콜을 사용하는 Linux 커널 버전
⚔️ 공격 벡터
원격의 공격자가 조작된 SCTP ASCONF Delete-IP 메시지 및 SACK 패킷을 전송하여 발생
🛡️ 대응 방법
SCTP 관련 패치가 적용된 최신 Linux 커널로 업데이트
🔧 검증 코드
현재 실행 중인 커널 버전을 확인하여 해당 취약점이 해결된 패치 버전인지 확인합니다.