Fragnesia (CVE-2026-46300): ‘Dirty Frag’ 패치를 우회하는 새로운 리눅스 LPE

이 블로그 글의 AI 요약으로 바로 가기

이번 달에 세 번째 긴급 재부팅 창이 뜨는 걸 원치 않으신가요?
KernelCare는
다운타임이나 서비스 중단 없이 재부팅 없이 리눅스 커널 패치를 적용합니다.

*업데이트 (2026-05-18, 13:00 UTC): AlmaLinux ELS/FIPS, Debian 11, Debian 12, EL8 계열, Rocky Linux 10, Oracle Linux 8, Oracle Linux 8 UEK 7, Oracle Linux 9, Oracle Linux 9 UEK 7, Ubuntu 22.04 (Jammy), Ubuntu 24.04 (Noble)용 재부팅 없이 적용 가능한 패치가 main 및 ePortal 피드에서 제공됩니다.

요약

내용: 리눅스 커널의 XFRM ESP-in-TCP 처리 방식에 존재하는 결함으로 인해, 권한이 없는 로컬 사용자가 setuid 바이너리를 포함한 읽기 전용 파일에 속한 캐시된 페이지를 제어된 방식으로 수정할 수 있습니다.

영향: 페이지 캐시 수정을 통한 로컬 권한 상승(루트 권한 획득). 디스크에 저장된 파일은 변경되지 않은 채로 유지되지만, 메모리에 캐시된 사본은 변경됩니다.

영향을 받는 시스템: 이미 Dirty Frag 수정 패치를 적용한 커널을 포함하여, 해당 skbuff 코드 경로를 실행하는 시스템. 공개된 PoC(개념 증명)는 버그를 유발하기 위해 CONFIG_INET_ESPINTCP가 필요하므로, 이 옵션을 제외하고 빌드된 커널은 이 익스플로잇을 차단합니다. 그러나 근본적인 skbuff 결함은 다른 경로를 통해 접근될 수 있습니다. 기본적으로 비특권 사용자 네임스페이스를 제한하는 배포판(예: Ubuntu의 AppArmor 구성)은 공개된 PoC를 부분적으로 차단합니다.

취약점 악용 현황: 공개 직후 GitHub에 공개 PoC가 게시되었습니다.

CVE ID: CVE-2026-46300

대응 조치: 취약한 ESP 모듈을 비활성화하거나, 패치가 제공되는 대로 공급업체 패치 또는 라이브 패치를 적용하십시오.

KernelCare 지원 현황 (2026년 5월 18일 13:00 UTC 기준): AlmaLinux ELS/FIPS, Debian 11, Debian 12, EL8 계열, Rocky Linux 10, Oracle Linux 8, Oracle Linux 8 UEK 7, Oracle Linux 9, Oracle Linux 9 UEK 7, Ubuntu 22.04 (Jammy), Ubuntu 24.04 (Noble)의 main 및 ePortal 피드에서 재부팅 없이 적용 가능한 패치가 제공됩니다.

kcarectl --update # pulls the patch if your kernel is in scope
kcarectl --patch-info | grep cve-2026-46300

공개 현황: 공급업체가 권고 사항을 발표하고 하위 커널 관리자가 백포트를 완료함에 따라 기술적 세부 사항, 영향을 받는 버전 안내 및 완화 조치 권장 사항이 변경될 수 있습니다.

5일 전, 리눅스 개발팀은 ‘Dirty Frag’에 대한 수정 패치를 배포했다. 오늘, 보안 전문가들은 이와 유사한 또 다른 취약점을 다루고 있다.

Fragnesia(CVE-2026-46300)는 리눅스 커널의 XFRM ESP-in-TCP 하위 시스템을 노리는, 최근 공개된 로컬 권한 상승 취약점입니다. 이 취약점은 V12 Security 팀과 협력 중인 William Bowling이 오늘, /usr/bin/su 파일을 덮어쓰고 루트 권한을 획득하는 작동하는 개념 증명(PoC)과 함께 오늘 공개되었습니다.

이 정보는 GitHub 과 X에 즉시 공개되었으며, 공개 유예 기간은 없었습니다. 이 기사가 작성된 시점에는 아직 CVE가 할당되지 않았으며, 후보 상류 수정안은 netdev에 올라와 검토 및 병합을 기다리고 있습니다.

Fragnesia가 주목받는 이유는 단순히 이 취약점 자체 때문만이 아니라, 그 시기와 배경 때문입니다. (Bowling이 제출한) 후속 패치 후보안은 Dirty Frag 수정 사항(f4c50a4034e6)를 이 패치가 “수정”하는 두 커밋 중 하나로 명시하고 있습니다. 이는 원래의 Dirty Frag 수정 조치가 이전에 잠재되어 있던 버그를 사실상 악용 가능한 형태로 노출시켰음을 의미합니다. Wiz의 분석 글에 따르면, 김현우(원래 Dirty Frag을 보고한 사람) 역시 프래그네시아가 Dirty Frag 패치의 의도치 않은 부작용으로 나타났음을 인정했다.

더 큰 그림은 우려스럽습니다. 보안 담당자들은 일주일도 채 되지 않아 동일한 공격 경로를 두 번이나 패치해야 하는 반면, 악용 코드 개발자들은 패치가 배포되는 속도와 거의 맞먹는 속도로 새로운 공격을 개발하고 있습니다.

왜 프래그네시아가 중요한가

Fragnesia는 Dirty Frag와 완전히 별개의 버그 유형이 아닙니다. 이는 동일한 ESP/XFRM 공격 경로를 통해 발생하는 또 다른 악용 경로이며, 상류에서 제공된 원래의 Dirty Frag 수정 사항만으로는 이를 완전히 차단할 수 없습니다.

기술적 문제는 skb_try_coalesce()함수에 있습니다. 이 함수가 하나의 sk_buff 의 페이지 단편을 다른sk_buff SKBFL_SHARED_FRAG 마커를 제거합니다. 이는 입력 처리(특히 skb_has_shared_frag() 체크가 이를 결정합니다. 이 체크는 복제되지 않은 비선형 skb가 skb_cow_data()를 건너뛸 수 있는지 결정하는skb_has_shared_frag()체크가 무효화됩니다. 복사-쓰기(copy-on-write)를 건너뛰면, 공유 페이지 내에서 직접 인플레이스(in-place) 복호화가 이루어지게 됩니다.

다시 말해, Dirty Frag 수정 사항(f4c50a4034e6)는 shared-frag 마커가 정확하다고 가정하는 코드를 추가했습니다. 하지만 이 마커는 정확하지 않습니다. 후보로 올라온 Fragnesia 패치에는 두 가지 수정 사항: 태그를 가지고 있습니다. 하나는 Dirty Frag 커밋용이고, 다른 하나는 훨씬 오래된 2013년 커밋(cef401de7be8)용 태그가 하나 더 있습니다. 이는 근본적인 코얼레싱 버그가 수년 동안 존재해 왔음을 보여줍니다. Dirty Frag 수정 사항은 단지 이 버그를 유용하게 악용할 수 있게 만들었을 뿐입니다.

실제로 이 익스플로잇은 지난주 방어 측이 이미 우려했던 것과 동일한 결과를 초래합니다. 즉, 디스크에 있는 원본 파일을 건드리지 않고도 권한이 부여된 바이너리의 페이지 캐시를 변조하는 것입니다.

이미 다음을 비활성화하는 Dirty Frag 완화 조치를 적용한 경우 esp4, esp6, rxrpc를 적용했다면, 이미 공개된 Fragnesia PoC로부터 보호받고 있는 것입니다. 초기 업스트림 수정 사항만 적용했다면, 그렇지 않습니다.

이러한 차이는 운영 측면에서 중요한데, 이는 현대적인 커널 공격에서 방어자들이 점점 더 자주 목격하는 패턴을 뒷받침하기 때문이다. 즉, 복잡한 메모리 처리 버그에 대한 수정 사항 자체가 신속한 우회 기법 연구의 표적이 되고 있다.

이 취약점 공격의 작동 원리

대략적으로 설명하자면, 이 익스플로잇은 다음과 같이 작동합니다:

공격자는 다음을 사용하여 새로운 사용자 및 네트워크 네임스페이스를 생성합니다. unshare(CLONE_NEWUSER | CLONE_NEWNET) 를 사용하여 CAP_NET_ADMIN 권한을 획득합니다.
TCP 내 ESP 전송 모드의 보안 연결은 다음을 통해 설정됩니다. NETLINK_XFRM 를 사용하여 알려진 키를 가진 AES-128-GCM을 통해 설정됩니다.
이 익스플로잇은 다음을 사용하여 256개 항목의 키스트림 조회 테이블을 준비합니다. AF_ALG 암호화 인터페이스를 사용하여 256개 항목의 키스트림 조회 테이블을 생성하며, 가능한 모든 바이트 값을 해당 논스(nonce)에 매핑합니다.
파일 기반 페이지는 splice()를 사용하여 대기열에 추가됩니다.
소켓이 espintcp ULP 모드로 전환됩니다.
왜냐하면 skb_try_coalesce() 이전에 공유 프래그먼트 마커를 제거했기 때문에, 커널은 공유된 캐시된 페이지에서 직접 인플레이스 AES-GCM 복호화를 진행합니다.
선택된 키스트림 바이트를 대상 페이지와 XOR 연산을 수행하여 제어된 단일 바이트 쓰기 작업을 생성합니다. 페이로드가 모두 기록될 때까지 바이트 단위로 이 과정을 반복합니다.

공개 PoC는 캐시된 사본을 덮어씁니다.

/usr/bin/su 다음과 같이 실행되는 작은 위치 독립형 ELF 페이로드를 사용하여:

setresuid(0,0,0);

execve("/bin/sh");

이 익스플로잇은 정확히 한 번만 성공해야 하는 좁은 레이스 윈도우에 의존하지 않는다는 점에서 주목할 만합니다. 공격자는 원하는 바이트가 성공적으로 기록될 때까지 쓰기 연산을 반복적으로 수행하므로, 이 과정은 과거의 많은 커널 레이스 조건 익스플로잇보다 훨씬 더 결정론적입니다.

수정된 캐시된 페이지는 캐시에서 제거되거나 시스템을 재부팅할 때까지 유지될 수 있으며, 이는 디스크상의 파일 해시가 변경되지 않더라도 대상 바이너리를 반복적으로 호출하면 계속해서 루트 권한을 획득할 수 있음을 의미합니다.

누가 가장 큰 위험에 처해 있나요?

가장 위험이 높은 환경은 다음 요소들이 결합된 시스템입니다:

신뢰할 수 없는 로컬 코드 실행,
권한이 없는 네임스페이스를 활성화하고,
다중 테넌트 워크로드,
그리고 XFRM/ESP 커널에 대한 적극적인 지원.

따라서 다음 환경들을 우선적으로 고려하는 것이 특히 중요합니다:

쿠버네티스 워커 노드
공유 CI/CD 실행기
공유 호스팅 플랫폼
Bastion 및 점프 호스트
개발자용 워크스테이션
다중 테넌트 컨테이너 인프라

이러한 시스템의 경우, “로컬” 권한 상승 취약점이 더 이상 단순히 로컬에 국한되는 경우는 거의 없습니다. 해킹당한 컨테이너, 악성 CI 작업, 도난당한 SSH 키, 또는 애플리케이션 RCE(원격 코드 실행)는 모두 호스트 전체를 장악하는 발판이 될 수 있습니다.

KernelCare를 이용한 재부팅 없이 Fragnesia 패치 적용

위에서 언급한 시스템들(다중 테넌트 쿠버네티스 노드, 공유 CI 러너, 바스티온 호스트)의 경우, 실질적인 문제는 수정 사항을 실제로 얼마나 빨리 배포할 수 있느냐는 점입니다. TuxCare의 재부팅 없이 패치를 적용하는 도구인 KernelCare는 지난주 Dirty Frag 취약점이 공개된 지 24시간 이내에 해당 벤더의 수정 패치보다 앞서 EL8 커널 패밀리를 위한 재부팅 없는 패치를 배포했습니다. EL9, Ubuntu, Debian 및 Proxmox VE도 동일한 릴리스 주기로 뒤를 이었습니다. 이것이 바로 이 심각도 등급에서 '빠름'이 어떤 모습인지 보여주는 기준입니다.

Fragnesia의 경우, 이 과정이 조금 더 복잡해질 것입니다. 상류(upstream) 수정 사항은 여전히 netdev에서 검토를 기다리고 있는 상태이므로, 첫 번째 KernelCare 패치는 후보 버전을 기준으로 빌드될 것입니다. 만약 유지보수자가 병합한 버전이 달라진다면 재빌드가 필요할 것으로 예상됩니다. 또한 해당 후보 패치에는 2013년 커밋을 가리키는 Fixes: 태그가 포함되어 있어 skb_try_coalesce()에 대한 추가 검토가 있을 가능성이 높습니다. 즉, 처음 출시되는 재부팅 없이 적용 가능한 패치가 이 취약점에 대한 최종 패치가 아닐 수도 있습니다.

재부팅 없이 패치를 적용하는 경우 바로 이런 패턴이 나타납니다. 동일한 서브시스템에 대해 5일 만에 두 번의 패치가 적용되었는데, 두 패치 모두 벤더의 에러타가 반영되기 전에 공개 PoC가 나왔으며, 세 번째 패치도 곧 나올 것으로 보입니다. 다음 섹션에서 다루게 될 대안으로는 모듈 블랙리스트 지정, 네임스페이스 제한, 그리고 배포판에서 커널 패키지를 출시할 때 발생하는 예정에 없던 롤링 재부팅이 있습니다. 일주일 동안 쿠버네티스 노드가 두 번이나 비워졌습니다. CI 러너는 빌드 도중 재시작되었습니다. 아무도 계획하지 않은 바스티온 페일오버가 발생했습니다.

한 가지 솔직히 말씀드리자면, 일부 취약점 스캐너는 라이브 패치 적용 후에도 패치되지 않은 커널 패키지 버전을 계속 감지할 수 있습니다. 이는 스캐너의 탐지 로직이 실제 실행 중인 커널 상태를 따라잡지 못하기 때문입니다. 커널은 이미 보호된 상태입니다. 다만 대시보드에는 하루나 이틀 정도 동안 이 사실이 반영되지 않을 수 있습니다. 이에 따라 티켓 설명 내용을 적절히 작성하시기 바랍니다.

아직 KernelCare를 이용하지 않고 계시며 이번 주 패치 일정에 차질이 생겼다면, 지금이 바로 고려해 볼 만한 시기입니다. 6월 말까지 신규 고객 대상 할인 혜택이 제공됩니다. KernelCare 가입하기 →

완화

즉각적인 완화 조치

Dirty Frag에 사용된 것과 동일한 모듈 블랙리스트는 공개된 Fragnesia 익스플로잇도 차단합니다:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/fragnesia.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

만약 /etc/modprobe.d/dirtyfrag.conf 파일이 이전 완화 작업으로 인해 이미 존재하는 경우, 그대로 두어도 됩니다.

운영 관련 경고

비활성화 esp4 및 esp6 을 비활성화하면 strongSwan 또는 Libreswan을 사용하는 배포 환경을 포함하여 IPsec 및 ESP 기반 VPN 기능이 작동하지 않게 됩니다. WireGuard 배포 환경에는 영향을 미치지 않습니다.

rxrpc 는 AFS 클라이언트와 관련되어 있으며, 일반적인 서버에서는 비활성화해도 대체로 안전합니다.

이러한 완화 조치를 광범위하게 적용하기 전에 운영상의 종속성을 확인하십시오.

권한이 없는 사용자 네임스페이스 제한

Ubuntu 시스템은 AppArmor가 기본적으로 권한이 없는 사용자의 네임스페이스를 제한하기 때문에 공개된 PoC에 대해 부분적으로 저항합니다. PoC 자체는 사용자에게 다음을 비활성화하도록 지시합니다:

kernel.apparmor_restrict_unprivileged_userns=0

착취되기 전에.

RHEL 계열 시스템에서는 다음을 통해 유사한 수준의 보호 기능을 구현할 수 있습니다:

echo "user.max_user_namespaces=0" > /etc/sysctl.d/fragnesia.conf

sysctl --system

이는 부분적인 해결책에 불과합니다. 또한 루트리스 컨테이너, Flatpak, 샌드박스화된 브라우저 및 기타 네임스페이스에 의존하는 도구들의 작동도 방해합니다.

중복된 페이지 캐시 삭제

이 악용 코드는 캐시된 페이지만 수정하므로, 침해된 것으로 의심되는 시스템은 대응 조치를 취한 후 페이지 캐시 내용을 지워야 합니다:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

이렇게 하면 당장의 페이지 캐시 지속성은 제거되지만, 공격자가 이후에 더 지속적인 접근 경로를 확보하지 못했다고 보장할 수는 없습니다. 공격이 성공적으로 이루어진 경우, 호스트가 완전히 장악된 것으로 간주해야 합니다.

공급업체의 수정 사항 적용

사용 중인 배포판에 대한 공급업체 제공 커널 업데이트나 검증된 라이브 패치가 출시되면 이를 적용하십시오.

이 글이 게시될 당시, 윌리엄 보울링이 제안한 후속 패치는 다음과 같습니다:

[PATCH net] net: skbuff: 병합 시 shared-frag 마커 유지

netdev 메일링 리스트에 검토를 기다리고 있습니다. 패치는 작습니다. skb_try_coalesce() 함수 내의 SKBFL_SHARED_FRAG 플래그를 보존하도록 수정하는 내용입니다. 유지보수 담당자들은 이 패치의 일부를 곧 병합할 것으로 보이지만, 배포판 전반에 걸친 다운스트림 백포트에는 더 많은 시간이 소요될 것입니다.

이는 방어 측이 이를 일회성 대응 조치가 아닌, 지속적으로 발전해 나가는 패치 주기로 간주해야 할 수도 있기 때문에 중요합니다. 두 가지 수정 사항: 태그가 표시된 패치는 skb 병합 경로에 대한 더 광범위한 감사 작업이 필요함을 시사합니다.

탐지 지침

기존의 파일 무결성 검사 도구는 이러한 유형의 공격에 대처하기에 부적합합니다:

디스크에 저장된 해시 값은 여전히 정확합니다
AIDE와 Tripwire는 변경 사항이 없다고 보고할 수 있습니다
캐시 삭제나 재부팅 후에는 악의적인 변경 사항이 사라집니다

행동 감지 방식이 훨씬 더 유망하다.

가능한 신호로는 다음이 있습니다:

공유 해제(CLONE_NEWUSER | CLONE_NEWNET) 예상치 못한 프로세스에서
NETLINK_XFRM VPN 기능과 무관한 워크로드의 활동
비정상적으로 많은 AF_ALG 암호화 인터페이스 사용이 유난히 많음, 특히 짧은 루프에서
splice() 일반 파일에서 TCP 소켓으로의 작업 수행 후, 동일한 소켓에 대한 ULP 변경

이들 각각은 그 자체로는 본질적으로 악의적이지 않지만, 이들이 결합된 양상은 eBPF 도구, Falco, Tetragon 또는 Linux EDR 플랫폼을 활용한 런타임 탐지 규칙을 적용할 만큼 충분히 의심스럽습니다.

더 큰 그림

최근 리눅스 권한 상승 연구에서는 페이지 캐시 손상, 공유 메모리 소유권 문제, 그리고 다음과 같은 인플레이스 처리 버그에 대한 연구 결과가 지속적으로 집중되고 있습니다:

더티 파이프 (2022)
복사 실패 (2026)
더티 프래그 (2026)
프래그네시아 (2026)

그중 세 건이 불과 몇 주 만에 드러났다.

공통된 패턴이 점점 더 분명해지고 있습니다. 공유 메모리 소유권, 페이지 처리, 인플레이스 처리를 포함하는 고도로 최적화된 커널 경로는, 극단적인 경우의 가정이 성립하지 않을 때 계속해서 위험한 쓰기 연산을 발생시킵니다.

splice(), skb 병합, ESP 처리 및 페이지 캐시 상호 작용은 모두 성능 중심의 하위 시스템입니다. 공격자들은 소유권 세미언틱이 무너지면 이러한 최적화 기능이 신뢰할 수 있는 권한 상승 경로가 될 수 있음을 점점 더 입증하고 있습니다.

Fragnesia는 원래 Dirty Frag 패치가 적용된 직후에 등장했다는 점에서도 주목할 만합니다. V12 Security는 이 취약점을 발견하는 과정에서 에이전트형 AI 기반 보안 도구가 일부 기여했다고 밝혔으며, 이 주장을 어느 정도 신뢰하든 간에, 익스플로잇의 진화 속도는 점점 더 빨라지고 있습니다. 후보 패치에 포함된 Fixes: 태그가 2013년 커밋을 가리키고 있다는 사실은 이 버그 유형이 아직 완전히 해결되지 않았음을 시사합니다. 아마도 동일한 코드 경로 내에서 발견되기를 기다리고 있는 더 많은 불변 조건 위반 사례가 있을 것입니다.

디펜더들은 이 버그 클래스의 진화가 아직 끝나지 않았다고 가정해야 한다.

요약