리눅스 커널 SCTP UAF 권한 상승 취약점 (CVE-2026-64564)

NOW Briefing

Brief 1 리눅스 커널의 스트림 제어 전송 프로토콜(SCTP)에서 동적 주소 재설정 시 이미 해제된 메모리를 다시 참조하는 use-after-free 취약점(CVE-2026-64564, 별칭 SCTPhantom)이 공개됐습니다. 원인 코드는 2007년 12월 도입돼 커널 2.6.25에 포함된 뒤 약 18년간 남아 있었습니다.

Brief 2 Linux CNA는 조건을 갖춘 원격 SCTP 피어도 악성 ASCONF로 취약점을 유발할 수 있다고 평가했습니다. 다만 연구진이 공개 자료에서 실제로 입증한 것은 비특권 로컬 사용자의 root 권한 획득과 컨테이너 탈출입니다.

Brief 3 커널 6.6.148 / 6.12.101 / 6.18.42 / 7.1.6 이상으로 업데이트한 뒤 반드시 재부팅해야 합니다. SCTP를 쓰지 않는 시스템은 모듈이 올라오지 못하게 막는 것이 가장 확실한 임시 대응입니다.

‍

리눅스 커널 SCTP UAF 권한 상승 취약점 (CVE-2026-64564)

‍

■ 개요

‍

SCTP는 TCP·UDP와 같은 전송 계층 프로토콜입니다. 통신사업자 신호 처리나 일부 고가용성 서비스처럼 하나의 연결에서 여러 경로를 묶어 쓰는 환경에서 사용됩니다. 이번 취약점은 SCTP의 동적 주소 재설정 기능인 ASCONF에서 주소 삭제 요청을 처리하는 과정에서 발생합니다.

원인 코드는 2007년 12월 커밋 42e30bf3463c로 도입돼 커널 2.6.25에 포함됐고, 각 안정 브랜치에 패치가 반영되기 전까지 영향을 미쳤습니다. Linux CNA는 정상 SCTP 연결과 ADD-IP 협상 조건을 갖춘 원격 피어가 악성 ASCONF를 보내 취약점을 유발할 수 있다고 평가했습니다.

다만 원격에서 취약점을 유발할 수 있다는 평가와 root 권한 획득 익스플로잇은 구분해야 합니다. Tencent 연구진이 공개 자료에서 실제로 완료·검증한 것은 비특권 로컬 사용자의 root 권한 획득과 컨테이너 탈출입니다. 연구진은 커널 7.2-rc2, OpenCloudOS 6.6.119, Debian 13 6.12.95+deb13-amd64, Ubuntu 24.04 6.8.0-134-generic, Rocky/RHEL 9 벤더 5.14 계열에서 root 권한 획득을 확인했다고 밝혔습니다.

공개 시점 기준으로 전체 원격-to-root 익스플로잇은 공개되지 않았고, 실제 악용 사례나 독립 재현 보고도 확인되지 않았습니다. 노출 여부는 SCTP 모듈이 이미 적재됐는지, 또는 비특권 요청만으로 자동 적재될 수 있는지에 따라 달라집니다. 원격 공격에는 외부 SCTP 연결과 ADD-IP 협상이 필요합니다. 다중 사용자 서버, CI 러너, 쿠버네티스 다중 테넌트 노드는 로컬·컨테이너 공격 경로를 우선 점검해야 합니다.

‍

■ 요약

‍

항목	내용
CVE ID	CVE-2026-64564 (SCTPhantom)
CVSS	CVSS v3.1 9.8 / Critical (Linux CNA) CVSS v4.0 8.5 / High (Tencent)
취약점 유형	해제된 메모리 재사용(use-after-free), SCTP ASCONF DEL-IP 처리 취약점 (CWE 미할당)
영향	• 조건을 갖춘 원격 SCTP 피어의 악성 ASCONF로 커널 UAF 트리거 가능(Linux CNA 평가) • 비특권 로컬 root 권한 획득 가능(연구자 시연) • 컨테이너에서 호스트 탈출 가능(연구자 시연) • 커널 메모리 손상 및 시스템 크래시 유발 가능
취약 버전	커널 2.6.25 이상 (각 stable 계열 패치 이전)
패치 버전	6.6.148 이상, 6.12.101 이상, 6.18.42 이상, 7.1.6 이상, mainline 7.2-rc5 이상

‍

■ 취약점이 발생하는 원리

‍

SCTP는 하나의 연결(association) 안에서 상대방의 IP 주소별 전송 경로(transport) 객체를 관리합니다. 커널은 ASCONF 청크(SCTP의 메시지 단위)를 받으면 청크가 들어온 경로를 asconf->transport에 저장하고, 청크 처리나 응답 전송 때 이 값을 계속 사용합니다.

문제는 삭제 요청을 검사하는 기준과 실제 삭제 대상을 고르는 기준이 서로 달랐다는 점입니다. 커널은 "패킷의 출발지 주소는 삭제할 수 없다"는 규칙(ADDIP 4.3 D8)만 확인하지만, 삭제할 경로는 청크 안의 주소 파라미터로 선택합니다. 하나의 ASCONF 청크에 여러 DEL-IP 파라미터를 넣을 수 있기 때문에, 출발지와 다른 주소를 지정하면 검사를 통과하면서 asconf->transport가 가리키는 경로를 해제할 수 있습니다.

연구진이 제시한 순서는 [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]입니다. 뒤이어 와일드카드 DEL-IP를 처리할 때 커널은 같은 포인터를 주 경로 지정 함수 sctp_assoc_set_primary()에 다시 넘깁니다. 이때 이미 해제된 메모리를 참조하게 되며, 연결의 주 경로 필드(primary_path·active_path)에는 해제된 객체를 가리키는 포인터가 남습니다.

업스트림 패치(커밋 9b2854f86f0b)는 삭제할 경로가 현재 ASCONF 처리에 쓰이는 경로와 같으면 요청을 거부하도록 6줄을 추가했습니다.

/* [패치 전] net/sctp/sm_make_chunk.c - sctp_process_asconf_param() */
		if (!peer)
			return SCTP_ERROR_DNS_FAILED;

		sctp_assoc_rm_peer(asoc, peer);
		break;

/* [패치 후] */
		if (!peer)
			return SCTP_ERROR_DNS_FAILED;

		/* Don't free asconf->transport; a later wildcard DEL-IP
		 * parameter reuses it.
		 */
		if (peer == asconf->transport)
			return SCTP_ERROR_REQ_REFUSED;

		sctp_assoc_rm_peer(asoc, peer);
		break;

‍

■ 노출 조건과 영향 범위

‍

SCTP 모듈이 이미 올라와 있거나 자동으로 올라올 수 있는 시스템만 공격에 노출됩니다. 원격 공격에는 외부 피어가 SCTP 연결을 맺고 ADD-IP를 협상할 수 있는 환경이 필요합니다. 공개된 로컬·컨테이너 공격은 대상 환경에서 SCTP 소켓을 만들 수 있어야 합니다.

배포판마다 기본 설정도 다릅니다. 공개 메일링 리스트에 따르면 RHEL·Rocky Linux 9 계열은 SCTP 모듈을 기본 설치본이 아닌 별도 패키지(kernel-modules-extra)로 제공합니다. 이 패키지에는 blacklist sctp·blacklist sctp_diag 설정이 들어 있어 비특권 사용자의 요청만으로 모듈이 자동 적재되지 않습니다. 따라서 이 계열은 관리자가 패키지를 설치하고 모듈을 직접 올린 시스템만 영향을 받습니다.

모듈이 올라온 뒤 ASCONF를 활성화하는 방법도 처음 알려진 것보다 다양합니다. 연구진은 애초 시스템 전역 설정(net.sctp.addip_enable, net.sctp.addip_noauth_enable)을 켜야 한다고 봤습니다. 이후에는 이 값을 바꾸지 않고도 소켓 옵션(SCTP_ASCONF_SUPPORTED, SCTP_AUTH_SUPPORTED)만으로 기능을 켤 수 있다는 사실을 확인했습니다. 컨테이너 탈출에는 CAP_NET_ADMIN이나 CAP_SYS_ADMIN도 필요하지 않았습니다. 연구진은 기본 seccomp 프로파일을 유지한 환경에서 8번 시도해 6번 호스트 root 권한을 얻었습니다.

⚠️ WARN

net.sctp.addip_enable = 0 설정만으로 완전히 차단된다고 단정하기 어렵습니다.
소켓 옵션만으로 ASCONF를 켤 수 있으므로, 패치가 어려운 시스템에서는 sysctl 값만 바꾸지 말고 모듈 적재 자체를 막아야 합니다.

‍

■ 탐지 및 점검

‍

• uname -r로 실행 중인 커널 버전을 확인하고, 6.6.148 / 6.12.101 / 6.18.42 / 7.1.6 미만이면 패치 대상으로 분류합니다. 2.6.25 이상은 모두 원인 코드를 포함합니다. 배포판 벤더 커널은 업스트림 번호가 아니라 벤더 권고의 패키지 버전으로 판단합니다.

• lsmod | grep sctp를 실행하거나 /proc/net/protocols에 SCTP 항목이 있는지 확인합니다. 모듈이 올라와 있다면 로컬·컨테이너 공격에 노출된 것으로 보고, 외부에서 접근할 수 있는 SCTP 연결도 따로 확인합니다.

• 현재 모듈이 올라와 있지 않더라도 modprobe -c | grep sctp로 자동 적재 차단 설정을 확인합니다. 차단 설정이 없으면 비특권 프로세스가 SCTP 소켓을 만드는 것만으로도 모듈이 올라올 수 있습니다.

• RHEL·Rocky Linux 9 계열은 rpm -q kernel-modules-extra로 SCTP 모듈 제공 패키지의 설치 여부를 확인합니다. 설치돼 있지 않다면 oss-security 논의 기준으로 실제 노출 가능성은 낮습니다.

• 컨테이너 환경은 이미지가 아니라 노드 호스트의 커널 버전을 기준으로 점검합니다. 비특권 사용자 셸이 열려 있는 다중 사용자 서버와 CI 러너 노드를 먼저 확인합니다.

✅ CHECK

커널 패키지를 업데이트했어도 재부팅 전까지는 취약한 커널이 계속 실행됩니다.
점검 기준은 설치된 패키지 버전이 아니라 uname -r이 반환하는 실행 중 커널 버전입니다.

‍

■ 대응 방안

‍

• 6.6.148 / 6.12.101 / 6.18.42 / 7.1.6 이상, 메인라인은 7.2-rc5 이상으로 커널을 업데이트하고 재부팅합니다. Debian 13(trixie)은 보안 권고 DSA-6415-1로 linux 6.12.101-1을 배포했습니다.

• SCTP를 사용하지 않는 시스템은 /etc/modprobe.d/ 아래에 install sctp /bin/false 항목을 추가해 자동 적재를 막습니다. 설정 적용 뒤에는 modprobe -r sctp로 기존 모듈을 내리거나 시스템을 재부팅해야 합니다. 사용 중인 SCTP 소켓이 있으면 모듈을 내릴 수 없으므로 해당 프로세스부터 정리합니다.

• 쿠버네티스·컨테이너 호스트는 노드 커널부터 패치합니다. 컨테이너 이미지 갱신이나 런타임 설정 변경으로는 해결되지 않으며, 기본 seccomp 프로파일도 완화 수단으로 신뢰할 수 없습니다.

• 즉시 재부팅하기 어려우면 비특권 사용자가 셸에 접근할 수 있는 노드부터 패치합니다. 라이브 패치를 쓰고 있다면 배포판 벤더가 이 취약점의 수정 사항을 포함했는지 확인합니다.

• 개인 PC나 데스크톱 리눅스가 공격받을 가능성은 낮습니다. 대신 SCTP가 외부에 노출된 서버와 비특권 사용자가 코드를 실행할 수 있는 클라우드·CI 환경은 커널 패치 상태를 우선 확인해야 합니다.

💡 TIP

SCTP는 대부분의 웹·업무 서버에서 실제로 쓰이지 않습니다.
사용 여부가 불확실하다면 표준 서버 이미지에서 SCTP 모듈을 기본적으로 차단하는 편이 좋습니다. 이번 취약점뿐 아니라 앞으로 발견될 SCTP 취약점의 공격 표면도 함께 줄일 수 있습니다.