새로운 루트 익스플로잇의 배후에 있는 리눅스 pedit COW 취약점

위험 완화 조치를 찾고 계신가요? 바로 아래로 이동하세요 ↓

요약

내용: pedit COW(CVE-2026-46331)라고 불리는 리눅스 로컬 권한 상승 취약점. 커널의 act_pedit 트래픽 제어 액션에서 경계 검사 누락으로 인한 쓰기 오류가 발생합니다. tcf_pedit_act()는 패킷 헤더를 수정하기 전에 copy-on-write 범위를 한 번 계산하지만, 실행 시점에 타입 지정된 키가 추가하는 런타임 오프셋을 고려하지 못해, 비사유화되지 않은 페이지에 데이터를 기록하게 됩니다. 이로 인해 공유 페이지 캐시에 저장되는 부분적인 COW가 발생합니다.

영향: 작성자가 검증한 공개 개념 증명(PoC)을 통해, act_pedit 액션에 접근할 수 있고 비특권 사용자 네임스페이스가 사용 가능한 영향을 받는 시스템에서, 해당 시스템의 일반 비특권 사용자라면 누구나 손쉽게 루트 셸에 접근할 수 있습니다. 이 PoC는 setuid-root /bin/su의 캐시된 이미지를 변조하여 바로 루트 권한을 획득합니다. 레드햇은 이 취약점을 ‘중요(Important)’ 등급으로 평가합니다.

상태: 이는 당일 깜짝 발표가 아닌 N-day 취약점입니다. 이 수정 사항은 netdev 메일링 리스트에서 일반적인 데이터 손상 패치(“net/sched: pedit 부분 COW로 인한 페이지 캐시 손상 수정”)로 공개적으로 개발되었으며, CVE 번호나 보안 관련 표기는 없었습니다. kernel.org의 CNA는 2026년 6월 16일 병합 시점에 CVE-2026-46331을 할당했습니다. 이는 악용 가능한 세부 정보가 이미 공개된 지 몇 주가 지난 후였으며, 6월 17일에는 실제 공격에 활용 가능한 PoC가 공개되었습니다. 메인라인 및 안정판은 수정되었으며, Red Hat과 AlmaLinux는 에라타를 배포했습니다.

위험도: 로컬 공격 벡터, 필수 조건이 충족되면 실행 난이도가 낮음, 사용자 상호작용 불필요, 루트 권한 획득으로 이어지는 결정론적 페이지 캐시 손상, 공개된 작동 가능한 익스플로잇 코드 존재. 버그 유형: 메모리 손상을 유발하는 범위를 벗어난 쓰기(out-of-bounds write) 및 로컬 권한 상승. 본 문서 게시 시점에는 CVSS 점수가 확정되지 않았으며, Red Hat의 ‘중요(Important)’ 등급을 기준으로 조치를 취해야 합니다.

지금 바로 다음 조치를 취하십시오: 해당되는 경우(RHEL 8/9/10, AlmaLinux 8, Debian 13) 벤더에서 수정된 커널을 배포하고 시스템을 재부팅하십시오. KernelCare의 재부팅 없이 적용 가능한 패치는 아직 테스트 중이며, 어떤 피드에도 반영되지 않았으므로 이를 기다리지 마십시오. 패치를 적용할 수 있을 때까지는 tc pedit 규칙을 사용하지 않는 경우 act_pedit의 로딩을 차단하고, 비특권 사용자 네임스페이스를 제한하십시오. 관련 명령어와 고려 사항은 아래와 같습니다.

자세한 내용

CVE-2026-46331은 커널의 쓰기 오류를 통해 로컬에서 루트 권한으로의 실질적인 공격 경로를 만들어내는 또 다른 리눅스 페이지 캐시 손상 취약점입니다. 이 취약점은 트래픽 제어 하위 시스템, 특히 tc가 전송 중인 패킷의 헤더 바이트를 재작성하는 데 사용하는 act_pedit 패킷 편집 작업에 존재합니다.

불안한 점은 단순히 버그 자체뿐만이 아닙니다. 그 버그가 어떻게 드러났는지가 문제입니다.

이 업스트림 패치는 데이터 손상 수정 사항으로 공개적으로 논의되었으며, CVE 번호도 부여되지 않았고 명백한 보안 관련 맥락도 제시되지 않았습니다. CVE는 그 후인 6월 16일 병합 시점에 부여되었으며, 다음 날 공개적으로 악용 가능한 PoC가 이어졌습니다. 이로 인해 pedit COW는 방어 측에 있어 중요한 측면에서 ‘N-day’로 분류됩니다. 즉, 대부분의 팀이 CVE, 스캐너 규칙, 벤더 권고 사항 또는 패치 절차를 확보하기 전에, 악용 가능한 기술적 세부 사항이 공개 메일링 리스트에 노출되었기 때문입니다.

이 문제는 저희가 자체 모니터링을 통해 포착하지 못했습니다. 고객사의 에스컬레이션을 통해 보고된 사안이었는데, oss-security에는 한 번도 올라온 적이 없었고, 커널 CNA 스트림은 현재 저희 감시 목록에 포함되어 있지 않습니다. 이러한 사각지대는 ‘먼저 수정하고 나중에 CVE를 등록하는’ 커널 버그에 대한 교훈을 주는 사례이며, 바로 이 글이 작성된 이유 중 하나이기도 합니다.

저도 영향을 받나요?

다음 조건이 모두 충족될 경우, 호스트를 노출된 것으로 간주한다:

• 커널에는 취약점이 있는 act_pedit 코드 경로가 포함되어 있습니다.
• act_pedit 모듈은 이미 로드되어 있거나, 필요에 따라 자동으로 로드될 수 있습니다.
• 비특권 사용자 네임스페이스가 활성화되어 있어, 공격자가 이 익스플로잇에 필요한 네임스페이스 내 CAP_NET_ADMIN 권한을 획득할 수 있게 됩니다.
• 신뢰할 수 없거나 부분적으로만 신뢰되는 로컬 사용자가 해당 시스템에서 코드를 실행할 수 있습니다.

act_pedit는 pedit tc 액션이 설정되는 즉시 자동으로 로드되므로, lsmod에 아무것도 없는 상태라고 해서 문제가 해결된 것은 아닙니다. 다음 세 가지 조건을 모두 확인하십시오:

# Is the module loaded right now?
lsmod | grep -w act_pedit

# Can it be loaded on demand?
modinfo act_pedit 2>/dev/null | head -n 1

# Are unprivileged user namespaces available?
sysctl user.max_user_namespaces kernel.unprivileged_userns_clone 2>/dev/null

해당 액션을 실제로 사용하고 있는지 확인할 수도 있습니다. 오늘 pedit 규칙을 실행하지 않는 호스트에서 `tc actions list action pedit` 명령을 실행하면 결과가 비어 있습니다. 결과가 비어 있다고 해서 안전하다는 의미는 아닙니다. 네임스페이스 내부에서 규칙을 삽입할 수 있는 공격자는 여전히 해당 코드 경로에 접근할 수 있기 때문입니다. 하지만 이 결과는 권장되는 모듈 블랙리스트 완화 조치를 적용해도 안전한지 여부를 알려줍니다.

RHEL과 Debian에서는 기본적으로 비특권 사용자 모드가 열려 있습니다. Ubuntu에서는 kernel.apparmor_restrict_unprivileged_userns / _unconfined에 의해 제어되지만, 이 제어는 보안 강화 조치일 뿐 커널 수정 사항은 아닙니다. PoC는 24.04 버전에서 aa-exec 기법을 사용하여 이를 우회합니다. Ubuntu 26.04는 동일한 AppArmor 관련 이유로 PoC 테스트에서 “FAIL”을 보고하지만, 그 기반이 되는 커널은 여전히 취약한 상태입니다.

pedit COW란 무엇인가

pedit는 패킷 편집기(packet editor)의 약자로, 패킷이 구성된 tc 필터와 액션을 통과할 때 관리자가 패킷 헤더의 필드를 재작성할 수 있게 해주는 트래픽 제어 액션입니다. 취약점이 있는 함수는 net/sched/act_pedit.c 파일에 있는 tcf_pedit_act()입니다.

이는 ‘Dirty Pipe’, ‘Copy Fail’, ‘Dirty Frag’와 같은 계열의 문제입니다. 커널 루틴이 독점적으로 소유하지 않은 페이지에 데이터를 쓰면, 해당 쓰기 작업이 디스크상의 파일을 뒷받침하는 페이지 캐시 항목에 기록됩니다. 여기서 새로운 점은 트리거 지점입니다. 암호화 패스트 경로나 제로 카피 복호화 경로가 아닌, 권한이 없는 프로세스가 사용자 네임스페이스 내부에서 구성할 수 있는 패킷 편집 작업이 트리거 역할을 합니다.

대략적으로 말하자면, 이 버그는 쓰기 가능한 패킷 범위를 너무 일찍 계산한 데서 비롯됩니다. 패킷 데이터를 수정하기 전에 커널은 skb_ensure_writable()을 호출하여 대상 바이트를 전용으로 설정합니다. tcf_pedit_act()는 편집 키에 대한 루프가 시작되기 전에, tcfp_off_max_hint라는 미리 계산된 힌트를 사용하여 해당 범위를 한 번 계산했습니다. 이 힌트는 타입 지정 키가 추가하는 런타임 헤더 오프셋을 고려하지 않았습니다. 해당 키들은 실행 시점에 L2/L3/L4 헤더를 기준으로 오프셋을 결정하므로, 실제 쓰기 오프셋은 루프가 실행된 후에야 알 수 있습니다. 따라서 대상 영역의 일부는 결코 전용 영역으로 지정되지 않습니다. 이는 부분적인 COW(Copy-on-Write) 상태이며, COW가 적용되지 않은 영역에 쓰기를 시도하면 범위를 벗어난 크로스 페이지 쓰기 오류가 발생합니다.

skb는 sendfile을 통해 불러온 제로 카피 페이지를 참조할 수 있기 때문에, 그 범위를 벗어난 쓰기 작업이 실제 파일을 뒷받침하는 공유 페이지 캐시 메모리에 기록될 수 있습니다. 커널은 해당 패킷 메모리를 수정해도 안전하다고 판단하지만, 실제로는 이후에 이루어지는 쓰기 작업이 커널이 실제로 비공개화한 영역을 벗어나게 됩니다.

이 취약점 공격이 실제로 어떻게 작동하는가

공개 PoC(sgkdev/packet_edit_meme)는 act_pedit 액션, 제로 카피 페이지를 참조할 수 있는 소켓 버퍼, 비특권 사용자 네임스페이스, 페이지 캐시 등 네 가지 일반적인 요소를 연결하며, 힙 셰이핑이나 레이스 윈도우가 필요하지 않습니다.

1. 네임스페이스 및 권한. 권한이 없는 사용자 네임스페이스에서 공격자는 네임스페이스 내부의 CAP_NET_ADMIN 권한을 획득하며, 이는 공격자가 제어하는 네임스페이스 내에서 트래픽 제어 조치를 구성하기에 충분한 권한입니다.
2. 트래픽 제어 바인딩. 이들은 런타임 오프셋이 tcf_pedit_act()가 쓰기 가능하게 설정한 범위 밖으로 벗어나는 타입 지정 키를 사용하여 pedit 액션을 구성함으로써, 부분 COW 쓰기를 트리거합니다.
3. 페이지 캐시 표적화. 제로 카피 파일 참조를 네트워크 스택에 전달함으로써, setuid-root 권한을 가진 /bin/su의 캐시된 ELF 이미지에 범위를 벗어난 쓰기 작업을 시도합니다.
4. 페이로드. 이들은 캐시된 진입점을 setgid(0), setuid(0), execve(“/bin/sh”)와 동등한 쉘코드로 덮어씁니다.
5. 루트. 공격자는 네임스페이스를 벗어나 su 명령을 실행합니다. 공유 페이지 캐시가 조작된 이미지를 제공하면, 쉘코드가 루트 권한으로 실행됩니다.

디스크에 저장된 바이너리 파일은 절대 변경되지 않습니다. 손상된 부분은 페이지 캐시에만 존재하기 때문에, 루트 셸이 이미 열려 있는 상태에서도 파일 해싱 및 디스크 포렌식 분석 결과는 정상으로 나타날 수 있습니다. 여기서 중요한 유일한 전제 조건은 CAP_NET_ADMIN 권한을 가진 비특권 사용자 네임스페이스입니다. 이 네임스페이스는 RHEL과 Debian에서는 기본적으로 열려 있지만, Ubuntu에서는 게이트 처리되어 있습니다.

업스트림 수정 사항의 변경 내용

병합된 수정 사항(제목: “net/sched: act_pedit: 키별 쓰기 가능 SKB 범위 확장”)은 쓰기 가능 범위가 실제 오프셋을 따르도록 COW 경로를 재구성합니다:

• skb_ensure_writable() 함수를 키별 루프 내부로 이동시켜, 실제 쓰기 오프셋을 파악할 수 있게 합니다.
• 오프셋 산술 연산에 오버플로 검사를 추가하고, 부호 반전이 정의되지 않은 경우인 INT_MIN에 대해 offset_valid() 함수를 보호합니다.
• 음수 오프셋의 경우(예: 입력 시 이더넷 헤더 수정)에는 skb_cow()를 사용하여 헤드룸에 COW를 적용합니다.
• 이 방식은 공유 프래그를 포함하는 SKB를 초기 단계에서 선형화하므로, 제로 카피 페이지가 감지되지 않은 채 손상되는 일이 없습니다.

이는 단일 함수에 대한 독립적인 변경 사항입니다. KernelCare의 재부팅 없이 적용되는 패치는 보수적인 kpatch 방식의 패치와는 달리, 이 업스트림 수정 사항을 그대로 이식한 것입니다. 즉, tcf_pedit_act() 내부의 COW 경로를 키별 skb_ensure_writable() / skb_cow() 로직과 오프셋 보호 메커니즘을 그대로 적용하여 재구축합니다.

이 버그가 왜 간과되기 쉬웠는지

pedit-cow는 ‘명명된 긴급 사항’으로 개발자 측에 전달된 적이 없습니다. 이는 네트워킹 관련 데이터 손상 문제를 해결하는 패치처럼 보였으며, 소스 코드 트리에서도 그런 맥락으로 처리되었습니다.

이 점이 중요한 이유는 대부분의 패치 워크플로가 CVE 피드, 벤더 권고 사항, oss-security, 스캐너 업데이트 등을 모니터링하기 때문입니다. 이 문제는 보안상의 영향이 뒤늦게야 드러나는 경로를 따랐습니다. 즉, 패치가 먼저 확인되었고, 병합 단계에서 CVE가 등록되었으며, 그로부터 하루도 채 지나지 않아 PoC가 공개되었습니다. 이러한 유형의 커널 버그의 경우, ‘먼저 수정하고 나중에 CVE 등록’ 방식은 일반 기업 패치 프로세스가 해당 문제를 인식하기도 전에 공격자나 전문 연구자들이 악용 가능성을 파악할 수 있는 여지를 만들어 줍니다.

실무상 시사점: 페이지 캐시 손상, 부분적 COW(Copy-on-Write), 제로 카피 쓰기, 쓰기 가능 SKB 범위 처리에 관련된 공개 커널 수정 사항은 CVE나 PoC가 등장하기 전까지 잠재적인 보안 문제와 관련이 있을 수 있다고 간주해야 합니다.

누가 영향을 받나요?

이 문제는 크게 세 가지 요인에 달려 있습니다. 첫째, act_pedit를 로드할 수 있는지, 둘째, 권한이 없는 사용자의 사용이 허용되는지, 셋째, 사용 중인 배포판에 수정된 커널이 포함되어 있는지 여부입니다.

공개된 PoC를 통해 악용 가능함이 확인됨 (작성자 확인, 일반 사용자 권한에서 루트 권한까지):

• 6.12.0-228.el10 버전의 RHEL 10.0 – 별도의 플래그가 필요하지 않으며, userns는 기본적으로 열려 있음
• 6.12.90+deb13.1 버전의 Debian 13 trixie – 별도의 플래그가 필요 없음
• 6.17.0-22 버전의 Ubuntu 24.04.4 – –ubuntu aa-exec userns 우회 방법이 필요합니다

Ubuntu 26.04 (7.0.0-14)에서는 “FAIL”이 반환되지만, 이는 AppArmor 사용자 보안 강화 기능이 제대로 작동하고 있기 때문이지, 커널이 수정된 것은 아닙니다. 기본 커널은 여전히 취약한 상태입니다.

공급업체에서 수정된 경우 (패치된 커널을 배포하고 재부팅):

• RHEL 10 – RHSA-2026:27288
• RHEL 9 – RHSA-2026:27789
• RHEL 8 – RHSA-2026:27353; AlmaLinux 8용 재빌드 버전은 ALSA-2026:27353입니다(6월 22일 출시). RHSA-2026:27355는 8.8 EUS/TUS 버전입니다.
• 데비안 13 트릭시 – DSA-6355-1 (6월 21일 발표)

여기에 메인라인과 안정판 백포트도 포함됩니다.

영향을 받았으나 공급업체 측에서 아직 수정되지 않은 경우 – 현재로서는 임시 완화 조치만이 유일한 해결책이며, 패치가 출시되면 재부팅 없이 적용 가능한 범위가 가장 중요한 호스트:

• 데비안 11 및 12
• Ubuntu bionic부터 noble까지 (24.04.4는 확인된 PoC 대상입니다)

영향을 받지 않았거나 아직 열려 있는 경우:

• RHEL 7 / CentOS 7 – 영향을 받지 않습니다.
• Oracle UEK 6 및 UEK 7 – 개발자 게시판에서 진행 중으로 표시됨.

지금 바로 위험을 줄이세요

가장 안전한 방법은 실행 중인 커널을 즉시 보호하는 것입니다. 이를 위한 실질적인 방안은 세 가지가 있으며, 우선순위 순으로 나열하면 다음과 같습니다.

1. 패치 또는 재부팅 없이 적용되는 패치

벤더에서 수정된 커널이 있다면 이를 설치하고, 운영상 가능한 한 빨리 시스템을 재부팅하십시오. 부분적으로 신뢰할 수 있는 코드가 실행되는 호스트를 우선적으로 처리하십시오. 여기에는 쿠버네티스 노드, CI/CD 러너, 공유 호스팅, 개발자 및 빌드 시스템, 멀티테넌트 플랫폼, 그리고 신뢰할 수 없는 워크로드를 수용하는 컨테이너 호스트가 포함됩니다.

CVE-2026-46331에 대한 KernelCare의 재부팅 없이 적용 가능한 패치는 현재 활발히 개발 중이며, 업스트림 수정 사항과 비교하여 테스트가 진행되고 있습니다. 최신 적용 현황에 따르면, 아직 테스트, 메인 또는 ePortal 피드에 배포된 내용은 없습니다. 빌드가 반영되면 다음을 통해 확인해 주십시오:

kcarectl --patch-info | grep -i 'CVE-2026-46331'
kcarectl --info | grep kpatch-build-time      # build dated on or after the release

2. act_pedit를 사용하지 않는다면 이를 차단하십시오.

act_pedit는 pedit tc 액션이 구성되는 즉시 자동으로 로드됩니다. tc pedit 규칙을 실행하지 않는 경우(대부분의 호스트가 그렇듯이) 이 모듈이 로드되지 않도록 차단하십시오.

레드햇의 보안 공지(RHSB-2026-008)에서는 부팅 시 블랙리스트 적용을 권장하고 있습니다:

echo 'blacklist act_pedit' > /etc/modprobe.d/blacklist-act-pedit.conf

블랙리스트는 부팅 시 자동 로딩만 차단합니다. act_pedit는 규칙에서 이를 참조하는 즉시 필요에 따라 자동 로딩될 수 있으므로, 모듈의 경로를 /bin/true로 지정하는 설치 오버라이드를 사용하는 것이 더 확실한 차단 방법입니다:

echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf

그런 다음 해당 규칙이 로드되었는지 확인하고, 이를 기반으로 하는 활성 트래픽 규칙이 없는 경우에만 해당 규칙을 언로드하십시오:

lsmod | grep -w act_pedit && sudo rmmod act_pedit
lsmod | grep -w act_pedit || echo "act_pedit not loaded"

파일을 삭제하여 원상태로 되돌리려면:

sudo rm /etc/modprobe.d/disable-act_pedit.conf

영향 범위: 블록이 활성화된 상태에서는 action pedit을 사용하는 모든 트래픽 제어 구성이 로드되지 않습니다. 일부 컨테이너/CNI 및 QoS 설정은 이에 의존하므로, tc pedit 규칙이 필요한 호스트에는 이 설정을 적용하지 마십시오. 광범위하게 배포하기 전에 tc actions list action pedit 명령어를 통해 확인하십시오.

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

이 익스플로잇은 네임스페이스 로컬 CAP_NET_ADMIN 권한을 획득하기 위해 비특권 사용자 네임스페이스가 필요합니다. 비특권 사용자 네임스페이스를 닫으면 모듈 상태와 관계없이 공개 체인이 끊어집니다.

# EL family:
sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf

# Debian / Ubuntu:
sudo sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone = 0' | sudo tee /etc/sysctl.d/99-pedit-cow.conf

Ubuntu에서는 대신 기존 AppArmor 제어 설정(kernel.apparmor_restrict_unprivileged_userns / _unconfined)을 강화할 수 있으며, 이는 26.04 버전에서 기본 설정만으로도 PoC를 차단하는 방식입니다.

호환성 참고 사항: 비특권 사용자 네임스페이스는 루트 권한이 없는 컨테이너 런타임, 여러 CI 샌드박스, 비특권 unshare(1), 샌드박스화된 브라우저 및 Flatpak에서 필수적으로 요구됩니다. 강화된 워크로드나 호스팅 워크로드에서는 허용되지만, 개발자 호스트 및 컨테이너 호스트에서는 운영에 지장을 줄 수 있습니다. 광범위하게 배포하기 전에 테스트하십시오.

결정적인 순간

호스트에서 `no tc pedit rules → block act_pedit;` 규칙을 적용하지 않는 경우, 이는 더 제한적인 변경 사항입니다. pedit는 필요하지만 루트 권한이 없는 컨테이너나 권한이 없는 unshare는 필요하지 않은 경우, 대신 userns를 제한해야 합니다. 두 가지가 모두 필요한 경우, `patch` 또는 `rebootless patch`가 유일한 실질적인 해결책이며, 그때까지 신뢰할 수 없는 로컬 실행을 격리해야 합니다.

KernelCare 재부팅 없이 적용되는 패치

2026년 6월 23일 18:30 UTC 기준 현황: KCARE-27230 통합 티켓 하에서 활발히 테스트 중입니다. 현재 test, main, ePortal 피드에는 아직 릴리스된 버전이 없습니다. 배포판별 작업은 KCARE-27167 (EL10), KCARE-27223 (EL9), KCARE-27159 (EL8), KCARE-27204 (Debian 13)에서 추적되고 있습니다.

빌드가 테스트 피드에 반영되면 다음 명령을 실행하여 적용하십시오:

kcarectl --update --prefix test

검증이 완료되면 다음 예정된 실행 시점에 제공되거나, 필요에 따라 수시로 불러올 수 있습니다:

kcarectl --update

확인:

kcarectl --patch-info | grep -i 'CVE-2026-46331'

탐지

pedit-cow의 경우, 침해 발생 후 확인할 수 있는 신뢰할 만한 징후가 없습니다. 손상된 데이터는 페이지 캐시에 존재하며, 디스크에 저장된 바이너리 파일은 그대로 유지되고, 캐시된 페이지가 제거되거나 시스템이 재부팅되면 증거가 사라집니다. 따라서 이 경우 파일 무결성 검사는 신뢰도가 낮은 지표에 불과합니다.

주목할 만한 행동 신호:

• 트래픽 제어 패킷 편집 기능을 실행하지 않는 호스트에서 act_pedit 모듈이 예기치 않게 로드됩니다.
• 평소에는 네트워크 설정을 전혀 하지 않는 사용자나 프로세스에서 비정상적인 tc 활동이 감지되었습니다.
• setuid 바이너리 실행 직전에 권한이 없는 사용자 네임스페이스를 생성합니다.
• 정당한 사유 없이 트래픽 제어 활동에 이어 발생하는 su, sudo 또는 셸 실행.

tc 실행 및 모듈 로딩 감사:

auditctl -w /sbin/tc -p x -k tc_exec
auditctl -w /usr/sbin/tc -p x -k tc_exec
grep act_pedit /proc/modules

악용이 의심될 경우, 페이지 캐시를 지워 디스크에서 원본 바이트를 다시 불러오도록 하세요:

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

이를 ‘차단’으로 간주하고, ‘복구’로 보지 마십시오. 공격자가 이미 루트 권한을 획득한 상태라면, 강제 퇴출 조치만으로는 그 이후에 공격자가 구축한 지속성을 제거할 수 없습니다. 노출 기간 동안 신뢰할 수 없는 로컬 사용자가 셸 액세스 권한을 가졌던 모든 호스트는 잠재적으로 침해된 것으로 간주해야 합니다.

왜 pedit-cow 같은 버그가 계속 재발하는가

pedit-cow, Dirty Pipe, Copy Fail, Dirty Frag는 세부 사항은 다르지만 한 가지 공통된 패턴을 공유합니다. 바로 성능 중심의 패스트 패스가 페이지에 쓰기가 안전한지에 대해 잘못된 가정을 한다는 점입니다. 각 사례에서 쓰기 작업은 커널이 자신이 소유하고 있다고 믿었던 페이지에 도달했으며, 페이지 캐시는 설계상 공유되는 특성 때문에 피해를 입게 되었습니다. 즉, 파일을 읽는 모든 사용자는 동일한 물리적 페이지를 보게 되므로, 해당 페이지에 단 한 번의 잘못된 쓰기 작업만으로도 실행 가능한 바이트를 읽는 권한이 있는 코드에서 이를 감지할 수 있게 됩니다.

이러한 버그가 위험한 이유는 바로 “로컬 메모리 손상”을 실질적인 위협으로 전환하기 때문입니다. 공격자는 파일 권한을 우회하거나 디스크상의 내용을 수정할 필요가 없습니다. 단지 권한이 있는 코드가 해당 내용을 읽거나 실행할 수 있을 만큼 충분히 오랫동안 캐시된 사본을 손상시키기만 하면 됩니다.

근본적인 해결책은 “최적화를 중단하라”는 것이 아닙니다. 커널의 메모리 처리 경로 전반에 걸쳐 페이지 소유권을 더욱 강력하게 보장하는 것이야말로 근본적인 해결책입니다. 이는 커널에서 성능에 가장 민감한 부분을 건드리기 때문에 시간이 오래 걸리는 작업입니다. pedit-cow는 이 계열의 마지막 버그가 아닐 것입니다. 또한 이는 왜 당일 대응이 점점 더 어려워지고 있는지를 보여줍니다. 많은 조직이 상황을 명확히 파악하기도 전에, 취약점이 겉보기에는 평범해 보이는 패치에서 CVE로, 그리고 공개된 루트 익스플로잇으로 확산될 수 있기 때문입니다.

우선순위별 개선 조치 체크리스트

1. 패치. 공급업체에서 수정한 커널(RHEL 8/9/10, AlmaLinux 8, Debian 13)을 배포한 후 시스템을 재부팅하십시오. KernelCare의 재부팅 없이 적용되는 패치를 기다리지 마십시오. 해당 패치는 아직 어떤 피드에도 포함되어 있지 않습니다.
2. 패치를 적용할 수 없는 부분은 위험을 완화하십시오. tc pedit 규칙을 적용하지 않는 경우 act_pedit를 차단하거나, 여유가 있다면 권한이 없는 사용자의 접근을 제한하십시오.
3. 로컬 액세스 권한을 점검하십시오. 공유 호스트, CI/CD 실행 환경, 빌드 서버 및 멀티테넌트 시스템에서 셸 액세스 권한을 가진 사용자를 확인하십시오. 해당 기간 동안 필요하지 않은 권한은 취소하십시오.
4. 검색. 5월 말 메일링 리스트 게시물을 시작으로 노출 기간에 대해 탐지 휴리스틱을 실행하십시오.
5. 패치 적용 후 시스템을 재부팅하십시오. 이렇게 하면 오래된 커널과 함께 잠재적으로 손상되었을 수 있는 캐시된 페이지들이 모두 제거됩니다.

참조

• NVD – CVE-2026-46331: https://nvd.nist.gov/vuln/detail/CVE-2026-46331
• CVE.org 기록 – CVE-2026-46331
• GitHub 권고 사항 GHSA-cr2w-747q-47qc
• Red Hat RHSB-2026-008 – 트래픽 제어 권한 상승 취약점 및 Red Hat CVE 페이지
• 공급업체 정정 사항: RHSA-2026:27288 (RHEL 10), RHSA-2026:27789 (RHEL 9), RHSA-2026:27353 (RHEL 8 = AlmaLinux ALSA-2026:27353; RHSA-2026:27355는 8.8 EUS/TUS 변형입니다), DSA-6355-1 (Debian 13)
• 데비안 보안 추적기 – CVE-2026-46331
• 공개 PoC (Massimiliano Oldani, 2026년 6월 17일): https://github.com/sgkdev/packet_edit_meme
• netdev 스레드: v2 및 v3 LKML 미러; 스레드 루트는 Spinics에 있음
• Stable fix commits (git.kernel.org/stable/c/<hash>): 899ee91156e5, 2bec122b9fb9, 3dee9d0c198f, b198ed4e5258
• KernelCare 추적: 통합 이슈 KCARE-27230; 재부팅 없이 적용 가능한 패치 CL gerrit 256818; 배포판별 KCARE-27167 / 27223 / 27159 / 27204

모든 커널에 패치를 적용할 수 있으며, 재부팅이 필요하지 않습니다. 아직 KernelCare를 사용하지 않으신 분이라면, 지금이 바로 재부팅 없이 패치를 적용하는 방식이 긴급 유지보수 시간이나 가동 중단 없이 중요한 리눅스 시스템을 어떻게 보호하는지 확인해 볼 좋은 기회입니다.

KernelCare에 대해 자세히 알아보세요 →