CVE-2026-99165 in Linux
요약
\~에 의해 VulDB • 2026. 10. 28.
리눅스 커널에서 다음 취약점이 해결되었습니다:
sctp: 연결 대기 후 출력 스트림 재검증
메시지 인터리빙이 활성화된 경우, 첫 번째 전송은 데이터 청크를 생성하기 전에 연결 확립을 기다립니다. 이 대기는 소켓 잠금을 해제하며, 핸드셰이크 처리는 피어에서 광고한 수신 스트림 수에 따라 출력 스트림 수를 줄일 수 있습니다. 그런 다음 sctp_stream_init()는 제거된 모든 스트림의 확장 구조체를 해제합니다.
송신자는 대기 전에 확인했던 스트림으로 재개됩니다. 만약 해당 스트림이 피어에 의해 제거되었다면, 나중에 sctp_outq_tail()에서 NULL인 확장 구조체를 역참조하게 됩니다. 치명적인 oops 정책은 호스트를 패닉 상태로 만듭니다.
KASAN: [0x38-0x3f] 범위 내 null-ptr-deref
RIP: sctp_outq_tail+0x49e/0xaa0 콜 트레이스: sctp_primitive_SEND sctp_sendmsg_to_asoc sctp_sendmsg
범위 검사만으로는 불충분합니다. 스트림 재구성 중 잠금이 해제되는 동안 출력 수가 다시 증가할 수 있으며, 이때 이전에 축소 과정에서 해제된 확장 구조체가 재생성되지 않습니다. 이로 인해 스트림은 유효한 범위 내에 있지만 그 확장 구조체는 NULL 상태가 될 수 있습니다. 전송 버퍼 대기에도 동일한 문제가 존재합니다.
범위 검사 및 확장 구조체 검사를 헬퍼 함수로 추출하고, 소켓 잠금을 해제하는 각 전송 경로 대기 후 두 가지 검사를 모두 반복 수행하십시오. 잠금이 다시 획득되면 데이터 생성 및 큐잉 동안 검증 상태가 안정적으로 유지됩니다.
연결 대기 후 검증에 실패하면 자동 생성된 연결은 이미 확립되어 있습니다. 기존 호출자 경로를 통해 프로토콜, 카운터 및 소켓 상태의 불일치를 초래할 수 있는 직접적인 해제가 아닌, 상태 머신 소유권 하에 있도록 유지하기 위해 ESRCH를 반환하십시오.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.