CVE-2026-31431 'Copy Fail': SMEP·SMAP·KASLR을 전부 무력화하는 데이터 전용 공격의 구조

2026년 4월 29일, 2017년 이후 출시된 사실상 모든 주요 Linux 배포판에서 비권한 로컬 사용자가 루트 권한을 획득할 수 있는 커널 취약점 CVE-2026-31431(Copy Fail)이 공개됐다. 732바이트짜리 Python 스크립트 한 줄로 재현되는 이 제로데이는 서버·데스크톱·임베디드 시스템 전체를 위협하며, 공개 PoC(Proof-of-Concept)까지 배포돼 긴급 대응이 요구된다.

경쟁 조건 없이 결정론적으로 동작하는 취약점

CVE-2026-31431은 Linux 커널의 algif_aead 모듈, 즉 AF_ALG 소켓 인터페이스의 AEAD(Authenticated Encryption with Associated Data) 크립토 템플릿 authencesn에 존재하는 로직 결함이다. CVSS 점수 7.8(High)로 분류된 이 취약점은 경쟁 조건(race condition)이나 타이밍 의존성 없이 결정론적(deterministic)으로 동작한다는 점에서 기존 로컬 권한 상승 취약점과 근본적으로 다르다.

영향 범위는 Linux 커널 4.x ~ 6.x(2017년 이후 빌드된 모든 커널), Ubuntu 24.10 이하 전 버전(26.04 Resolute부터 미영향), Debian·RHEL·CentOS·Fedora·SUSE·Amazon Linux 2·Arch Linux, Kubernetes 노드·공유 커널 컨테이너·CI/CD 러너 환경, x86_64·ARM64·RISC-V 등 다중 아키텍처를 아우른다. 파급력이 특히 심각한 이유는 멀티테넌트 Linux 시스템에서 어떤 로컬 사용자도 루트가 될 수 있다는 점이다. 페이지 캐시가 호스트와 컨테이너 사이에 공유되는 구조상 컨테이너 탈출(container escape) 원시 공격 벡터로도 활용될 수 있다.

⤢✕

합리적인 변경이 만든 재앙

CVE-2026-31431은 단일 버그가 아니라, 수년에 걸쳐 이루어진 세 가지 독립적인 커널 변경의 불운한 조합에서 비롯됐다. 2011년 IPsec 처리를 위한 HMAC+CBC 조합 알고리즘으로 authencesn AEAD 크립토 래퍼가 도입됐고, 2015년에는 유저스페이스에서 커널 암호화 API에 접근할 수 있도록 AF_ALG 소켓의 AEAD 지원(algif_aead.c)이 추가됐다. 그리고 2017년, algif_aead.c에 인플레이스(in-place) 최적화(커밋 72548b093ee3)가 도입됐는데 이것이 근본 원인이다.

2017년 최적화 코드는 AAD(Additional Authenticated Data)와 암호문을 TX SGL(scatter-gather list)에서 RX 버퍼로 복사한 뒤, 태그 페이지를 sg_chain()으로 참조 연결하고 req->src = req->dst로 설정했다. 이 과정에서 splice()로 주입된 페이지 캐시 페이지가 쓰기 가능한 목적지 scatterlist 안으로 들어갈 수 있게 됐다.

authencesn(hmac(sha256),cbc(aes)) 알고리즘은 ESN(Extended Sequence Number) 재배열을 위해 assoclen + cryptlen 오프셋에 4바이트 스크래치 공간을 사용한다. 취약한 코드 경로에서는 이 4바이트 쓰기가 splice된 파일의 인메모리 캐시 데이터, 즉 페이지 캐시 안으로 들어간다. 결과적으로 공격자는 파일 권한을 우회해 읽기 가능한 임의 파일의 페이지 캐시를 4바이트 단위로 오염시킬 수 있다.

실제 공격은 /usr/bin/su(또는 다른 setuid 바이너리)를 읽기 전용으로 열어 페이지 캐시에 로드하고, AF_ALG 소켓(SOCK_SEQPACKET, AF_ALG)으로 authencesn AEAD 컨텍스트를 구성한 뒤, splice()로 타겟 파일의 페이지 캐시 페이지를 소켓의 RX 경로에 삽입하는 순서로 진행된다. AEAD 복호화 요청을 실행하면 ESN 스크래치 쓰기가 페이지 캐시 오염을 유발하고, 오염된 setuid 바이너리를 실행하면 루트 셸을 얻는다. 경쟁 조건이 없고 커널 버전 오프셋 계산도 필요 없으며, 재컴파일이나 컴파일된 페이로드도 불필요하다. 표준 라이브러리만 쓰는 순수 Python 스크립트로 동작한다는 점이 이 취약점을 특히 위험하게 만든다.

보호 기법이 우회당한 게 아니라 발동조차 안 했다

현대 Linux 커널은 권한 상승 공격을 막기 위한 다층적 메모리 보호 아키텍처를 갖추고 있다.

보호 기술	도입 버전	역할
SMEP	Linux v3.0 (2011)	커널 모드에서 유저스페이스 페이지 실행 차단
SMAP	Linux v3.7 (2012)	커널 모드에서 유저스페이스 메모리 읽기/쓰기 차단
KASLR	Linux v4.12 (2017, 기본 활성화)	커널 주소 공간 무작위화
kASan	Linux v4.9 (2016)	Use-after-free 및 OOB 버그 런타임 탐지
CFI	Linux v6.1+	제어 흐름 무결성 강제
KPTI	Linux v4.15 (2018)	Meltdown 이후 커널/유저 페이지 테이블 격리

CVE-2026-31431의 핵심은 위 보호 기법들을 우회하는 것이 아니라 처음부터 발동시키지 않는다는 데 있다. 공격은 유저스페이스 코드를 커널 모드에서 실행하거나 유저 메모리에 접근하는 방식이 아닌, 정상적인 커널 암호화 API 경로를 통해 이루어지므로 SMEP/SMAP과는 무관하다. 커널 주소를 직접 조작하지 않고 페이지 캐시라는 정상적인 커널 데이터 구조를 활용하므로 KASLR도 무관하다. 4바이트 쓰기가 할당된 버퍼 범위 내처럼 보이기 때문에 kASan의 OOB 탐지 경계를 벗어나지 않아 탐지가 미흡하고, 제어 흐름을 하이재킹하지 않고 데이터만 오염시키므로 CFI와도 무관하다.

⤢✕

Copy Fail은 커널의 암호화 API 인프라 자체를 쓰기 원시 연산(write primitive)으로 전용하는 방식으로 동작하기 때문에, 기존 메모리 보호 아키텍처가 설계상 방어할 수 없는 영역을 공략한다. 이번 취약점은 커널 보안 연구 커뮤니티에서 오래전부터 경고해온 **데이터 전용 공격(data-only attack)**의 현실적 위험을 다시 한번 증명했다. 코드 실행 흐름이 아닌 데이터 자체를 오염시키는 공격은 SMEP/SMAP/CFI와 같은 코드 실행 기반 보호 기법의 사각지대에 위치한다. 향후 커널 보안 아키텍처는 페이지 캐시 쓰기 권한 검증, 암호화 API 출력 경로의 격리, 데이터 무결성 보호(Data-Only CFI) 같은 방향으로 발전할 필요가 있다.

배포판별 대응 타임라인

날짜	이벤트
2026년 3월 23일	Linux 커널 보안팀에 취약점 보고
2026년 4월 1일	업스트림 수정 커밋 병합 (`a664bf3d603d`)
2026년 4월 22일	CVE 번호 할당 (CVE-2026-31431)
2026년 4월 29일	공개 공시 및 PoC 배포
2026년 4월 30일	주요 배포판 패치 패키지 배포 완료

업스트림 수정은 단순히 2017년 최적화를 되돌리는(revert) 것이 아니라, 관련된 3개의 커밋을 포함한 세트로 구성됐다.

Ubuntu는 CVE 공시 당일 공식 블로그를 통해 수정 패치 제공을 발표했다. Ubuntu 26.04 LTS(Resolute) 이상은 영향을 받지 않으며, 그 이하 버전은 모두 패치가 필요하다.

# Ubuntu 패치 적용
sudo apt update && sudo apt upgrade -y linux-image-generic
sudo reboot

Debian Security Tracker를 통해 CVE-2026-31431이 추적되며, Debian 12(Bookworm) 및 11(Bullseye)용 패치가 배포됐다.

# Debian 패치 적용
sudo apt update && sudo apt full-upgrade -y
sudo reboot

Red Hat은 RHEL 8, 9 전 마이너 버전에 대한 어드바이저리를 발행했다. KernelCare는 AlmaLinux 9.6-FIPS 및 UEK7에 대한 검증을 완료하고 라이브 패치(live patch)를 배포하고 있다.

# RHEL/CentOS 패치 적용
sudo dnf update kernel -y
sudo reboot
# 또는 KernelCare 라이브 패치 (리부트 없음)
/usr/bin/kcarectl --update

SUSE는 SLES 15 SP4 이상 전 버전에 대한 보안 업데이트를 배포했다.

# SUSE 패치 적용
sudo zypper patch --category security
sudo reboot

AWS는 Amazon Linux Security Center를 통해 패치를 제공하며, EKS 노드 이미지 업데이트도 함께 배포했다.

패치를 즉시 적용할 수 없는 환경에서는 algif_aead 커널 모듈을 비활성화하는 방법으로 취약점을 차단할 수 있다.

# 즉시 모듈 언로드
sudo rmmod algif_aead

# 재부팅 후에도 영구 비활성화
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo update-initramfs -u  # Ubuntu/Debian
# 또는
sudo dracut --force       # RHEL/Fedora

다만 이 완화 조치는 IPsec을 AF_ALG를 통해 처리하는 환경에서는 일부 기능에 영향을 줄 수 있으므로, 운영 환경에 따라 영향도를 먼저 평가해야 한다.

임베디드·IoT는 패치가 훨씬 어렵다

서버나 데스크톱 환경과 달리 임베디드·IoT 시스템은 구조적 특성 탓에 커널 보안 업데이트 관리가 근본적으로 어렵다. 상당수 임베디드 기기는 특정 커널 버전으로 하드코딩된 펌웨어를 쓰고, 벤더가 제공하는 BSP(Board Support Package)가 업스트림 보안 패치를 반영하지 않으면 사용자가 독립적으로 커널을 교체하기 어렵다(펌웨어 잠금). 산업용 IoT 기기·의료 기기·자동차 ECU는 10~20년 운용을 전제로 하는데, 커널 수명 주기(LTS 커널도 통상 6년)와 어긋난다(긴 수명 주기). 보안 업데이트를 자동으로 수신·적용하는 인프라 자체가 없는 기기도 현장에 상당수 배포돼 있고(OTA 업데이트 인프라 부재), 공유 Linux 시스템에서 동작하는 산업용 제어 시스템이나 엣지 서버는 Copy Fail의 직접적인 공격 대상이 된다(멀티 로컬 사용자 환경).

⤢✕

단기(07일)로는 배포된 모든 기기에서 lsmod | grep algif_aead로 모듈 로드 상태를 확인하고, 로드된 기기에 algif_aead 비활성화 설정을 배포하며, 다중 사용자 환경의 임베디드 시스템에 대한 접근 제어를 강화한다. 중기(14주)로는 벤더에 BSP 보안 업데이트 일정을 확인·촉구하고, Yocto/Buildroot 기반 자체 빌드 환경이라면 업스트림 패치 커밋을 반영하며, OTA 업데이트 파이프라인으로 패치를 배포한다. 장기(1개월 이상)로는 커널 LTS 버전 업그레이드 로드맵을 수립하고, 보안 업데이트 서비스 계약(예: Wind River, Yocto Long-Term Support)이 없는 기기는 교체하거나 네트워크 격리 계획을 세우며, 임베디드 리눅스 보안 정책에 커널 모듈 최소화(불필요 모듈 블랙리스트) 원칙을 적용한다.

Copy Fail은 컨테이너에서도 동일하게 동작한다. 컨테이너는 호스트와 커널을 공유하므로, 컨테이너 내 비권한 프로세스가 이 취약점을 통해 호스트 루트를 획득할 가능성이 있다. Kubernetes 환경에서는 모든 노드에서 커널 패치 적용 여부를 uname -r로 확인하고, 신뢰할 수 없는 코드를 실행하는 CI/CD 러너 노드를 격리하며, Seccomp 프로파일로 AF_ALG 소켓 생성을 차단하는 완화 대안을 검토해야 한다.

# Seccomp를 이용한 AF_ALG 소켓 차단 예시 (Kubernetes Pod spec)
# securityContext.seccompProfile에 커스텀 프로파일 적용
# socket(AF_ALG, ...) 시스템 콜 차단

CVE-2026-31431(Copy Fail)은 2017년 이후의 모든 주요 Linux 커널에 영향을 미치는 고위험 로컬 권한 상승 취약점으로, 경쟁 조건 없이 732바이트 Python 스크립트만으로 루트 권한을 획득할 수 있다는 점에서 즉각적인 커널 패치 적용이 필수적이다. SMEP·SMAP·KASLR 등 기존 커널 메모리 보호 아키텍처를 정상 API 경로를 통해 완전히 우회하는 데이터 전용 공격이라는 특성상, 보호 기법 자체의 진화 방향에도 중요한 시사점을 남긴다. 서버·데스크톱 환경은 배포판 패키지 관리자를 통해 즉시 패치를 적용하고, 패치가 지연되는 임베디드·IoT 환경에서는 algif_aead 모듈 비활성화와 접근 제어 강화를 즉시 시행해야 한다.