# Linux 커널 취약점은 배포판에 사전 알림이 가지 않는다 > Clean Markdown view of GeekNews topic #29067. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29067](https://news.hada.io/topic?id=29067) - GeekNews Markdown: [https://news.hada.io/topic/29067.md](https://news.hada.io/topic/29067.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-01T18:33:14+09:00 - Updated: 2026-05-01T18:33:14+09:00 - Original source: [openwall.com](https://www.openwall.com/lists/oss-security/2026/04/30/10) - Points: 1 - Comments: 1 ## Topic Body - Linux 커널의 로컬 권한 상승 취약점인 **CopyFail**은 최근 커널의 “make-me-root” 취약점 중 **가장 심각한 축**에 듦 - 문제는 4.14의 commit `72548b093ee38a6d4f2a19e6ef1948ae05c181f7`에서 도입됐고, **6.18.22**, **6.19.12**, **7.0**에서 수정됨 - 6.19.12와 6.18.22는 4월 11일에 **수정 백포트**가 포함됐지만, Longterm 6.12, 6.6, 6.1, 5.15, 5.10에는 당시 수정이 들어가지 않음 - 수정은 오래된 커널에 **clean apply**되지 않았고, 즉시 배포가 필요한 상황에서는 IPSec의 **`authencesn` 모듈 비활성화 패치**가 임시 대응으로 사용될 수 있음 - Linux 커널 취약점은 보고자가 **linux-distros ML**로 가져오지 않는 한 배포판에 사전 알림이 가지 않으며, 이번 건에서도 **heads-up**이 발생하지 않음 --- ### CVE-2026-31431 영향 범위와 수정 상태 - **CopyFail**은 Linux 커널의 로컬 권한 상승 취약점이며, 최근 커널의 “make-me-root” 취약점 중 가장 심각한 축에 듦 - 문제는 **4.14**의 commit `72548b093ee38a6d4f2a19e6ef1948ae05c181f7`에서 도입됐고, 6.18.22, 6.19.12, 7.0에서 각각 수정됨 - [6.18.22 수정 commit]() - [6.19.12 수정 commit]() - [7.0 수정 commit]() - 6.19.12와 6.18.22는 4월 11일에 **수정 백포트**가 포함된 상태로 릴리스됨 - Longterm 6.12, 6.6, 6.1, 5.15, 5.10에는 당시 수정이 들어가지 않았고, upstream stable queue에서도 보이지 않았음 - 2017년에 도입된 문제라면 오래된 커널들도 영향을 받는지 확인 필요함 ### 배포판 사전 통지와 임시 대응 - 해당 수정은 오래된 커널에 **clean apply**되지 않음 - 즉시 배포할 필요가 있는 상황에서 백포트를 시도했지만, 몇 가지 **API 변경** 때문에 확신 있게 진행하기 어려웠음 - 임시 대응으로 IPSec의 `authencesn` 모듈을 비활성화하는 패치를 사용할 수 있으며, IPSec 전문가가 아니어도 “덜 나쁜 선택”에 가까움 - [0001-crypto-disable-authencesn-module-for-CVE-2026-31431.patch](): CVE-2026-31431 대응용 `authencesn` 모듈 비활성화 패치 - Linux 커널 취약점은 보고자가 **linux-distros ML**로 가져오지 않는 한 배포판에 사전 알림이 가지 않음 - 이번 건에서는 linux-distros ML을 통한 **heads-up**이 발생하지 않았음 ## Comments ### Comment 56655 - Author: neo - Created: 2026-05-01T18:33:15+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47965108) - 링크된 글의 작성자인 **Sam James**는 Gentoo 개발자임 어쨌든 이건 재앙에 가깝고, 배포판들이 수정본을 배포하기 전에 exploit을 공개한 건 매우 무책임했음 이걸로 얼마나 많은 shared hosting 업체가 해킹됐을지 알 수 없음 또한 **kernel security team**과 배포판 maintainer 사이에 소통이 없어 보인다는 점도 걱정됨 전자가 후자에게 알릴 거라고 기대하게 되지만, 실제로는 취약점을 찾은 사람이 책임져야 하는 구조처럼 보임 - 보고한 대상에 패치가 들어간 뒤 **30일 후 공개**하는 것 자체에는 문제가 없다고 봄 참고로 Google Project Zero도 비슷하게 “90+30” 정책을 씀: [https://projectzero.google/vulnerability-disclosure-policy.h...]() 진짜 문제는 kernel security team과 배포판 maintainer 사이에 소통 채널이 없다는 점임 취약점을 발견한 사람이 모든 downstream에 따로 보고할 책임을 져서는 안 됨 kernel 팀이 배포판 보안 담당자 목록에 패치의 중요도와 30일 뒤 공개 일정을 알려야 했음 - 이번 공개는 보안보다 **마케팅**에 가까웠음 공개 페이지에도 “Is your software AI-era safe?”, “Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem”, “[Try Xint Code]” 같은 문구가 있음 혼란이 커질수록 제품이 더 매력적으로 보이게 만드는 방식임 - 사용자이자 관리자로서는 “매우 무책임했다”는 데 동의하지 않음 **Responsible Disclosure**라는 표현은 “Secure Boot”처럼 언어적으로 잘 설계된 표현이고, 실제로는 내 컴퓨터와 나 사이에 있는 기업·재단 중간 조직들의 평판 관리를 위한 것처럼 보임 그들은 내 개별 컴퓨터가 취약한지보다 “RHEL이 취약하다”, “Ubuntu가 취약하다”는 말을 못 하게 하는 데 관심이 있음 취약점은 어차피 존재하므로, 조용히 수정되기만 기다리기보다 위험을 알고 줄일 기회가 있는 편이 낫다고 봄 즉각적인 공개만이 무책임하지 않은 선택이라고 생각함 - 공개 절차 자체에 대한 입장을 떠나, 이걸로 해킹당한 hosting provider라면 이미 질 수밖에 없는 구조였음 서로 신뢰하지 않는 tenant workload를 **단일 shared kernel** 아래에서 돌리는 건 괜찮지 않음 Kernel LPE는 드문 일이 아니고, 이번 건 특히 단순하고 이식성이 좋았을 뿐이며 원시 capability 자체는 CNE commodity에 가까움 - **Linux kernel**은 보안 경계로 쓰기에 적합하지 않음 shared hosting을 하면서 해킹당하지 않으려면 gVisor나 Firecracker VM 같은 다른 수단을 써야 함 이를 보안 경계로 쓰는 중요한 시스템은 Android 정도인데, APK 설치에 사용자 승인, 엄격한 SELinux와 seccomp 정책, GrapheneOS hardening이 있어 완화됨 이번 경우에도 완화가 성공했음: [https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...]() - “Linux kernel 취약점의 경우 reporter가 linux-distros ML에 직접 가져가지 않는 한 배포판에 사전 알림이 없다”는 식으로 말하는 이유가 이해되지 않음 reporter가 배포판들과 직접 조율해야 한다는 건 Linux 프로젝트에 대한 높은 수준의 지식을 전제로 함 취약점 제보자가 Linux kernel의 모든 downstream 소비자와 직접 일할 책임을 져서는 안 됨 그렇게 따지면 Linux를 장비에 쓰는 모든 제조사에도 직접 연락해야 하나 싶음 제보자는 Linux에 책임 있게 공개하고 패치가 들어갈 때까지 기다린 것만으로도 충분히 했다고 봄 Linux 프로젝트 내부에 보안 취약점에 대한 권한과 책임을 가진 사람들이 있어야 하고, downstream distro에 알리는 일도 그들이 해야 한다고 생각함 - 특히 reporter에게 배포판 팀에 먼저 알리지 말라고 명시적으로 요청한다는 점에서 더 그렇다 [https://docs.kernel.org/process/security-bugs.html]() ```As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community. ``` - reporter가 자기 웹사이트에서 **Ubuntu/RHEL/SUSE** 같은 특정 배포판을 확인해 언급할 시간은 있었음 적어도 그 배포판들의 보안팀에는 알리는 게 책임 있는 행동이었을 것 같음 - reporter가 Ubuntu, RedHat, Amazon, SUSE를 명시적으로 지목하는 웹사이트를 만들고도 그들에게 알리지 않은 게 합리적이라고 보기는 어려움 그 배포판들이 kernel 팀의 downstream이라는 걸 몰랐을 리도 없어 보임 - 필수 요건은 아닐 수 있지만, reporter들이 **안전한 remediation**보다 유명세에 더 관심이 있었기 때문에 모두가 더 고통받게 됐다고 봄 - Linux distro에 이런 보안 이슈를 보고하는 방법을 찾는 건 아주 쉬움 Google 검색만 해도 나옴: [https://share.google/aimode/eihDKXZJy94Z5lC1p]() 이걸 생각하지 않고 모두를 exploit에 노출시키는 건 이해하기 어렵고, 일부 법역에서는 중범죄여도 이상하지 않다고 봄 - disclosure와 관련해 가장 흥미로운 교환은 이 링크에 있음 [https://www.openwall.com/lists/oss-security/2026/05/01/3]() “우리는 누구에게도 사전에 알릴 수 없다. 그러면 모든 것에 대해 모두에게 알려야 하기 때문이다. 법률·정부 기관들이 우리가 운영할 수 있도록 동의한 유일한 정책이 그것이라 어쩔 수 없다”는 **greg k-h**의 답변임 - Linux를 좋아하지만, 이건 어리석은 정책이라고 봄 - reporter 탓을 그만하고 **kernel 프로세스**를 고치라고 요구해야 함 Linux kernel은 더 이상 장난감 프로젝트가 아니고, 여러 회사에 고용된 full-time 직원들이 있음 배포판에 알리는 일은 임의의 개인이 아니라 그들이 처리했어야 함 - 발표용, 사실상 마케팅용 블로그 글에서 특정 distro들을 affected로 이름까지 찍었다면, 공개 전에 **heads-up**을 주는 게 적절하고 기대되는 행동이라고 봄 RHEL 14 같은 언급을 그렇게 넣지 않았다면 이렇게까지 비난받지는 않았을 것 같음 이건 개인 보안 연구자나 학계가 아니라, 전문적인 커뮤니케이션 부서를 둔 보안 회사가 distro maintainer를 겨냥해 손가락질한 상황임 - 배포판과 kernel 개발자들이 high severity 패치에 대해 소통하고 빠르게 움직여야 하는 건 맞음 하지만 reporter가 그 일이 일어나기를 기다리지 않았기 때문에 실제 사람들이 피해를 입었을 수 있고, 그 책임은 reporter에게 있음 - 취약점을 보고하는 것과, 아무나 가져다 쓸 수 있는 **강력한 exploit**을 공개하는 건 전혀 다른 문제임 주요 distro에 먼저 알리지 않고 세상에 풀어놓은 건 무책임했음 - AF_ALG가 모듈이 아니라 kernel에 직접 링크된 kernel을 쓰는 사람들을 위해 **eBPF 기반 workaround**를 올렸음: [https://github.com/Dabbleam/CVE-2026-31431-mitigation]() 지금 production에서 돌리고 있고 공격을 완화하며, 지금까지 예상치 못한 부작용은 보이지 않음 - `nosuid`와 아마 `nodev`는 기본 filesystem mount option이어야 한다고 봄 `/dev`는 이미 특수한 devtmpfs이고, initrd의 최소 `/dev`는 필요하다면 initrd tmpfs rootfs를 `dev`와 `suid`로 명시적으로 mount하면 됨 SUID binary가 아무 데나 “존재”할 수 있게 두는 건 큰 보안 위험임 외부 저장매체를 mount했을 때 그 block device 안의 SUID binary들이 악성인지 어떻게 검증할 수 있나 싶음 게다가 이 exploit은 SUID binary를 실행하는 사용자가 그 binary를 읽을 수도 있어야 동작하는 것으로 보임 non-root 사용자가 SUID binary에 read 권한을 가질 이유는 없음 **NixOS**는 이걸 올바르게 처리함 일반 패키지 설치 디렉터리인 `/nix/store`에는 SUID가 없고, 패키지가 그 밖으로 새지 않기 때문에 다른 mountpoint에는 안전하게 `nosuid`를 쓸 수 있음 예외는 executable-only SUID wrapper만 안전하게 담는 단일 목적의 `/run/wrappers.$hash` 디렉터리뿐임 - 나도 suid를 싫어하지만, 여기서 **suid**가 본질적인 문제는 아님 exploit되는 버그는 사실상 임의의 page cache poisoning을 가능하게 함 그 시점이면 이미 게임이 끝난 상태이고, suid 프로그램을 patch하는 건 root shell을 얻는 가장 쉬운 방법일 수는 있어도 유일한 방법은 아님 - proof of concept exploit은 말 그대로 한 가지 공격 벡터를 보여주기 위한 것일 뿐임 다른 방법은 많음 개념 증명 exploit만 막는 것이 목표라면 blacklist 같은 더 쉬운 방법도 있지만, 그게 더 안전하게 만들어 주지는 않음 이 취약점으로는 **page cache**를 조작할 수 있음 `ld.so`를 조작해 임의 system call에 hook을 걸거나, uid를 0으로 바꾸거나, 그 외 여러 방식으로 권한 상승이 가능함 mount point는 이 문제와 관련이 없음 물론 사용자 쓰기 가능 영역에서 suid를 막고 suid 파일 읽기를 막는 건 늘 좋은 생각이지만, 그건 다른 이유 때문임 NixOS도 이 취약점을 고치지 못하며 다른 배포판과 마찬가지로 취약함 - read 권한이 없으면 binary를 실행할 수 없고, 그건 말이 되지 않음 binary를 실행하려면 디스크에서 읽어 메모리에 로드해야 함 실제로 특정 binary에 read 권한은 있지만 executable 권한이 없다면 linker를 직접 호출해 실행할 수도 있음 예를 들어 `/bin/ld.so.1 /path/to/binary`처럼 호출하면 linker가 binary를 읽고 로드한 뒤 `exec()` 호출 없이 entry point로 점프함 - 아래 **Bleeping Computer** 링크에 패치가 준비될 때까지의 잠재적 대응책이 나와 있음 [https://www.bleepingcomputer.com/news/security/new-linux-cop...]() - 이 workaround는 영향받은 코드가 모듈로 컴파일된 kernel에만 적용됨 RHEL, Fedora, Gentoo는 모두 이 코드를 kernel에 직접 빌드하도록 설정되어 있음 패치나 config 변경이 없으면, Sam이 Gentoo에서 암시했듯이 해당 배포판들은 계속 취약함 - RedHat과 그 파생 배포판에서는 영향받은 코드가 모듈이 아니라 **static으로 컴파일**되어 있어서 이 대응책이 동작하지 않음 - **NixOS**도 알림을 받지 못했음 [https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...]() - 어떤 배포판도 알림을 받지 못했음 - **Hyperbola GNU**는 정치적 이유와 안정성 때문에 아직 Python 3.8을 쓰고 있어서 안전했음 - Ubuntu는 패치를 내놨고, 패치 전후로 테스트도 완료됨