---
title: "리눅스 커널 취약점, 배포판에 사전 알림이 없을 수도 있다는 현실"
published: 2026-04-30T16:43:47.000Z
canonical: https://jeff.news/article/2006
---
# 리눅스 커널 취약점, 배포판에 사전 알림이 없을 수도 있다는 현실

리눅스 커널 로컬 권한 상승 취약점인 CVE-2026-31431 대응 과정에서, 배포판들이 사전에 알림을 받지 못했다는 점이 드러났어. 취약점은 2017년 리눅스 4.14에 들어간 커밋에서 시작됐고, 일부 최신 stable 커널에는 수정이 들어갔지만 여러 장기지원 커널에는 아직 깔끔한 백포트가 없는 상태야.

- 리눅스 커널 취약점 CVE-2026-31431을 두고, 배포판들이 사전에 경고를 받지 못했다는 얘기가 oss-security 메일링 리스트에서 나왔음
  - Gentoo의 Sam James가 밝힌 핵심은 이거임: 제보자가 linux-distros 메일링 리스트에 따로 공유하지 않으면, 리눅스 커널 취약점은 배포판에 사전 알림이 가지 않을 수 있음
  - 이번 건도 그런 사전 공유가 없었다고 함. 즉, 배포판 입장에서는 패치 릴리스나 공개 논의를 보고 뒤늦게 대응해야 하는 구도가 된 셈

- 문제의 취약점은 꽤 오래된 커널 코드에서 시작된 로컬 권한 상승 이슈로 보임
  - 원문 스레드에 따르면 취약점은 2017년에 리눅스 4.14에 들어간 커밋 72548b093ee38a6d4f2a19e6ef1948ae05c181f7에서 유입된 것으로 정리돼 있음
  - 수정 커밋은 6.18.22, 6.19.12, 7.0 계열에 각각 들어갔고, 링크된 stable 커밋도 3개가 제시됐음
  - 한 참여자는 이걸 “최근 커널 취약점 중 최악급 make-me-root 취약점”이라고 표현했음. 말 그대로 로컬 사용자가 루트 권한을 얻는 류라서 표현이 세다기보다 위험도가 실제로 빡센 쪽

> [!WARNING]
> 로컬 권한 상승 취약점은 “외부에서 바로 뚫리는 RCE가 아니니까 괜찮다”로 넘기면 안 됨. 이미 낮은 권한으로 들어온 공격자가 루트까지 올라가는 마지막 계단이 될 수 있음.

- 더 골치 아픈 부분은 장기지원 커널 쪽임
  - 6.18.22와 6.19.12는 4월 11일에 수정이 백포트된 릴리스가 나왔다는 언급이 있음
  - 그런데 6.12, 6.6, 6.1, 5.15, 5.10 같은 longterm 계열에는 당시 기준으로 수정이 들어가지 않았고, upstream stable queue에서도 보이지 않는다고 지적됨
  - 취약점이 4.14에서 유입됐다면 이 오래된 계열들도 영향권일 가능성이 있는데, 문제는 패치가 깔끔하게 적용되지 않는다는 점임

- Gentoo 쪽은 당장 쓸 수 있는 완전한 백포트 대신 우회책을 택하는 분위기임
  - Sam James는 직접 백포트를 시도했지만 API 변경 몇 가지에 걸렸고, 즉시 배포해야 하는 보안 대응에서 확신 없이 건드리기 어렵다고 설명함
  - 그래서 첨부 패치로 crypto 쪽 authencesn 모듈을 비활성화하는 workaround를 쓰겠다고 함
  - 본인도 IPSec 전문가는 아니지만 “덜 나쁜 선택”이라고 표현했음. 보안 패치가 기능 제한으로 이어지는 전형적인 운영자 눈물 버튼임

> [!IMPORTANT]
> 이번 이슈의 포인트는 “취약점이 있다”에서 끝나지 않음. 최신 stable에는 수정이 있는데 longterm 커널에는 아직 없고, 배포판 사전 통지도 보장되지 않는다는 공급망 타이밍 문제가 같이 터졌음.

- 한국 개발자나 인프라 운영자 입장에서는 커널 버전 확인을 대충 하면 위험함
  - “우리 서버는 LTS 커널이니까 안전하겠지”가 자동으로 성립하지 않음
  - 배포판 커널 패키지가 어떤 stable 커밋을 포함했는지, CVE-2026-31431에 대한 배포판 보안 공지가 나왔는지 확인해야 함
  - 특히 멀티유저 서버, CI 러너, 빌드 머신, 컨테이너 호스트처럼 낮은 권한 코드가 자주 실행되는 환경이면 우선순위를 높게 잡는 게 맞음

---

## 기술 맥락

- 이번 선택의 핵심은 “정식 백포트가 어렵다면 위험한 기능을 잠시 꺼서라도 공격면을 줄인다”예요. Gentoo 쪽이 authencesn 모듈 비활성화를 언급한 이유도 완성도 낮은 커널 패치를 급히 넣는 것보다, 영향을 받는 기능을 제한하는 쪽이 즉시 배포에는 더 예측 가능하다고 본 거예요.

- 커널 백포트가 어려운 이유는 단순히 패치 파일이 충돌나서가 아니에요. 2017년에 들어간 코드가 여러 커널 버전을 거치며 주변 API와 내부 구조가 바뀌었고, 보안 패치는 작은 실수 하나가 커널 패닉이나 우회 가능한 불완전 수정으로 이어질 수 있거든요.

- 운영 관점에서는 “수정 커밋이 upstream에 있다”와 “내 서버 커널에 반영됐다”를 분리해서 봐야 해요. 특히 6.12, 6.6, 6.1, 5.15, 5.10 같은 장기지원 계열을 쓰는 환경은 배포판 보안 패키지와 changelog까지 확인해야 실제 대응 여부를 알 수 있어요.

- linux-distros 사전 통지 문제도 꽤 중요해요. 배포판들이 미리 준비할 시간이 없으면 취약점 공개 직후 며칠 동안은 최신 stable 사용자, longterm 사용자, 배포판 패키지 사용자 사이에 보안 상태가 갈라질 수밖에 없어요.

## 핵심 포인트

- CVE-2026-31431은 로컬 사용자가 루트 권한을 얻을 수 있는 심각한 리눅스 커널 취약점으로 언급됨
- 수정은 6.18.22, 6.19.12, 7.0에 들어갔지만 6.12, 6.6, 6.1, 5.15, 5.10 장기지원 커널에는 아직 적용되지 않은 것으로 보임
- 리눅스 커널 취약점은 제보자가 linux-distros 메일링 리스트에 직접 공유하지 않으면 배포판이 사전 통지를 받지 못할 수 있음
- Gentoo 쪽은 즉시 배포 가능한 임시 대응으로 IPSec 관련 authencesn 모듈 비활성화 패치를 준비 중이라고 밝힘

## 인사이트

커널 보안에서 제일 무서운 건 취약점 자체만이 아니라, 수정이 공개된 뒤 장기지원 커널과 배포판 패키지까지 내려오는 시간차야. 서버 운영자는 커널 버전 숫자만 볼 게 아니라, 해당 취약점 패치가 자기 배포판 빌드에 실제로 들어왔는지 확인해야 함.