검증 범위. 기준 시각은 2026-11-11 16:30 KST이다. 패키지 버전과 출시 상태는 Ubuntu CVE 데이터(CVE JSON, 2026-11-10 17:01 UTC 갱신)와 Canonical 블로그(11-09 갱신)에서 확인했다. 어느 pocket에 올라갔는지는 Launchpad API(getPublishedSources)를 직접 조회해 확인했다. USN 페이지와 notices API는 작성 시점에 503을 돌려줘서 USN 번호와 릴리스의 대응은 확인하지 못했다. 그래서 이 글에는 그 대응을 적지 않았다. “내 판단”이라고 표시한 부분은 1차 출처가 아니라 필자의 추론이다. 공격 방법은 다루지 않는다.

이 글은 CVE-2026-98432에 관한 네 번째 글이다. 원리는 10/29 글에, 배포판별 대응 원칙은 11/02 글에 정리했다. 우분투 수정 커널이 늦어진 경위는 11/10 글에 있다. 이번 글은 그 기다림이 끝난 뒤, 즉 수정 커널이 나왔으니 실제로 깔고 확인하는 단계를 다룬다.

결론부터

  • 22.04(jammy), 24.04(noble), 26.04(resolute)의 기본 커널 linux가 모두 수정 버전으로 출시됐다. 블로그 갱신 시점(11-09)부터 -proposed 를 켤 필요가 없다는 것이 Canonical의 공식 입장이다.
  • 다만 24.04 수정 커널은 Launchpad 기준으로 아직 -updates pocket에만 있다. 22.04와 26.04는 -security에도 올라갔다. unattended-upgrades를 기본 설정으로 쓰는 24.04 서버라면 이 커널이 저절로 깔리지 않을 수 있다. 손으로 apt full-upgrade 해야 한다.
  • 다른 시리즈의 HWE 커널(linux-hwe-6.8 on 22.04, linux-hwe-7.0 on 24.04)은 아직 -proposed에만 있다. “24.04인데 7.0 커널”을 쓰는 서버는 아직 고쳐지지 않은 상태다.
  • 확인은 uname -r만으로는 부족하다. uname -r은 ABI 번호(6.8.0-149-generic)만 보여 준다. 패키지 버전 전체(6.8.0-149.149)는 /proc/version_signature에서 확인해야 한다.

1. 무엇이 나왔나 — 시리즈별 수정 버전과 pocket

Ubuntu CVE 데이터가 밝힌 수정 버전에 Launchpad 조회 결과를 붙이면 다음과 같다.

릴리스 소스 패키지 수정 버전 -updates 게시 -security 게시
22.04 jammy linux 5.15.0-203.213 11-05 23:22 UTC 11-09 19:11 UTC
24.04 noble linux 6.8.0-149.149 11-06 01:14 UTC 조회 시점 없음
26.04 resolute linux 7.0.0-43.43 11-06 01:14 UTC 11-10 09:56 UTC
22.04 jammy linux-hwe-6.8 6.8.0-149.149~22.04.1 — (-proposed만) —
24.04 noble linux-hwe-7.0 7.0.0-43.43~24.04.1 — (-proposed만) —

Canonical 블로그도 같은 표를 싣고 있다. 26.10(stonking)의 7.3.0-10.10도 수정 완료로 적혀 있다. 20.04 이하는 ESM으로 나갈 예정이고, 블로그 기준으로는 아직 테스트 중이다 (Canonical 블로그).

왜 pocket이 중요한가

우분투 아카이브에서 업데이트가 들어오는 길은 셋으로 나뉜다. -security는 보안 수정, -updates는 일반 업데이트, -proposed는 검증 중인 업데이트다. unattended-upgrades의 기본 설정(/etc/apt/apt.conf.d/50unattended-upgrades)은 ${distro_codename}-security와 ESM 출처만 허용한다. -updates 줄은 주석 처리돼 있다 (Ubuntu Server 문서 — Automatic updates).

그래서 같은 수정 커널이라도 어느 pocket에 있느냐에 따라 자동 갱신이 집어 가는지가 갈린다. 24.04는 조회 시점에 -updates에만 있으므로 기본 설정의 자동 갱신 대상이 아니다. 반대로 사람이 직접 apt update && apt full-upgrade를 돌리면 기본 sources.list에 -updates가 들어 있으므로 바로 깔린다. 커널은 비슷한 시점에 -security로도 복사되는 경우가 많지만, 지금 이 순간 그렇다는 보장은 없다. 그러니 기다리지 말고 손으로 올리는 편이 맞다고 본다. (내 판단)

2. 확인 — uname -r 하나로는 모자란 이유

Canonical은 확인 방법으로 uname -r와 dpkg -l 'linux-image*' | grep ^ii를 든다 (Canonical 블로그). 둘이 보여 주는 것은 다르다.

  • dpkg -l이 보여 주는 것은 설치된 커널이다. 깔기만 하고 재부팅하지 않았다면 수정 커널이 목록에 있어도 여전히 취약하다.
  • uname -r이 보여 주는 것은 지금 돌고 있는 커널이다. 다만 6.8.0-149-generic처럼 ABI 번호까지만 나온다. 업로드 번호(.149)가 빠져 있다.

이 CVE는 ABI 번호만 맞춰 봐도 대개 구분된다. 그래도 업로드 번호까지 확인하려면 우분투 커널이 노출하는 /proc/version_signature를 읽으면 된다. 첫 필드 뒤에 6.8.0-149.149-generic 꼴로 전체 버전이 나온다. 이 값을 dpkg --compare-versions로 수정 버전과 비교하면 사람의 눈대중이 끼어들 틈이 없다.

# 지금 돌고 있는 커널이 수정 버전 이상인지 (noble 예시, FIXED 만 바꿔 쓰면 된다)
FIXED=6.8.0-149.149          # jammy: 5.15.0-203.213 / resolute: 7.0.0-43.43
RUNNING=$(awk '{print $2}' /proc/version_signature | sed 's/-[a-z]*$//')
if dpkg --compare-versions "$RUNNING" ge "$FIXED"; then
  echo "OK  running=$RUNNING"
else
  echo "VULNERABLE running=$RUNNING (need >= $FIXED)"
fi

# 깔아 놓고 재부팅을 안 했는지
[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs

sed는 -generic, -lowlatency 같은 flavour 꼬리를 떼어 낸다. HWE 커널(~22.04.1 꼴)을 쓰는 서버라면 위 표의 HWE 줄이 아직 -proposed에만 있다는 점부터 확인해야 한다. 기본 linux 패키지가 고쳐졌다고 해서 HWE 커널이 고쳐진 것은 아니다.

3. 꺼 둔 쿠버네티스 노드를 다시 켜는 순서

필자의 홈랩 k3s 클러스터는 이 CVE 때문에 10월 29일부터 전 노드를 꺼 두었다. 수정 커널이 없는 상태에서 외부 연결을 받는 노드를 계속 띄워 두는 것보다 끄는 편이 낫다고 판단했기 때문이다. 노드는 26.04 한 대(control plane 겸 원격 접속 경유지)와 24.04 두 대다. 지금 돌던 커널은 각각 7.0.0-38과 6.8.0-147 / 6.8.0-139였다. 셋 다 기본 linux 계열이고 HWE가 아니므로 이번 수정 대상에 들어간다.

순서는 다음과 같이 잡았다. 이 순서는 공식 절차가 아니라 이 클러스터 사정에 맞춘 내 판단이다.

  1. control plane 노드부터 켠다. etcd 쿼럼과 API 서버가 먼저 서야 나머지 노드가 붙을 곳이 생긴다. 원격 접속도 이 노드를 거치므로 다른 노드를 손대려면 이게 먼저 살아 있어야 한다.
  2. 켜자마자 sudo apt update && sudo apt full-upgrade -y. Canonical 블로그는 apt upgrade를 권한다. 다만 커널 ABI가 바뀌면 메타 패키지가 새 패키지를 설치해야 하는데, apt upgrade가 이런 경우를 보류(kept back)하는 일이 있다. 그래서 full-upgrade 쪽이 확실하다. 커널만 콕 집어 올리는 메타 패키지 명령도 블로그에 실려 있다.
  3. sudo reboot 후 위 2절의 스크립트로 OK를 확인한다. 설치만 하고 재부팅하지 않은 상태는 패치하지 않은 것과 같다.
  4. 나머지 노드도 한 대씩 같은 절차를 밟는다. 이미 돌고 있는 클러스터라면 kubectl drain → 업그레이드·재부팅 → 확인 → kubectl uncordon 순서다. 전부 꺼져 있던 경우라면 drain할 파드가 없으니 업그레이드와 확인만 하면 된다.
  5. 재부팅 뒤 커널 밖의 문제를 따로 본다. 이 클러스터에서 실제로 겪은 일이 있다. 재부팅 후 호스트 방화벽이 다시 켜지면서 오버레이 네트워크(VXLAN)를 막아 파드 간 통신이 죽었다. 노드가 Ready로 떠도 파드끼리 통신이 안 될 수 있다. 판정은 새로 띄운 파드에서 클러스터 DNS 조회가 되는지로 한다.

부팅 직후의 취약 구간

1번과 2번 사이에는 아직 취약한 커널로 네트워크에 붙어 있는 구간이 생긴다. 이건 피할 수 없다. 업데이트를 받으려면 네트워크가 필요하기 때문이다. Ubuntu CVE 데이터는 완화책으로 nftables 규칙을 하나 싣고 있다. IP 옵션이 붙은(헤더 길이 > 5) IPv4 TCP 패킷을 입력 훅의 매우 앞쪽(priority −310)에서 떨어뜨리는 규칙이다. 다만 같은 문서가 이 규칙은 “위험을 줄일 뿐 완전히 막지는 못한다”고 적고 있다. 별도 네트워크 네임스페이스를 쓰는 컨테이너에는 따로 걸어야 한다는 단서도 달려 있다 (Ubuntu CVE JSON). Canonical 블로그는 한 걸음 더 나아가, MPTCP를 끄라는 식의 완화책이 돌고 있지만 보안 업데이트만이 적절한 완화책이라고 못 박는다.

가정용 공유기 뒤에서 들어오는 포트를 열지 않고, 외부 노출은 아웃바운드 터널로만 하는 구성이라면 이 짧은 구간의 실제 위험은 낮다고 본다. 반대로 공인 IP에 TCP 포트를 직접 열어 둔 서버라면 콘솔로 들어가 위 규칙을 먼저 건 뒤 업데이트하는 편이 낫다. (내 판단)

4. 수정 뒤 정리할 것

  • 임시 완화책을 걷는다. 패치 대기 기간에 위 nftables 규칙을 걸어 두었다면, 수정 커널로 재부팅한 것을 확인한 뒤에 제거한다. 제거 명령은 Ubuntu CVE 데이터의 완화 절에 함께 실려 있다. IP 옵션을 쓰는 정상 트래픽은 드물지만 0은 아니다. 남겨 둔 임시 규칙은 나중에 원인을 찾기 어려운 장애가 된다.
  • 감시 장치를 정리한다. 수정 출시를 기다리며 CVE 상태를 폴링하는 작업을 걸어 두었다면, 쓸모가 다했는지 판단한다. 필자는 출시 알림을 받는 용도로 하나를 돌렸다. 다만 이 글 기준으로 HWE 백포트가 아직 남아 있으니, 그 커널을 쓰는 서버가 있다면 바로 끄지 않는 게 맞다.
  • 자동 갱신 정책을 다시 본다. 이번처럼 수정 커널이 -updates에 먼저 들어오고 -security에는 늦게 들어오는 경우가 있다. 이걸 놓치지 않으려면 둘 중 하나를 골라야 한다. unattended-upgrades의 허용 출처에 -updates를 넣거나, 중대 CVE가 나오면 사람이 직접 확인하는 절차를 두는 것이다. 앞쪽은 보안이 아닌 변경까지 자동으로 들어온다는 비용이 따른다. 어느 쪽이 정답이라고 할 근거는 없고, 운영 성격에 따라 고를 문제다.

5. 버그 자체를 한 줄로 다시

IPv4 TCP 3-way 핸드셰이크에서 자식 소켓을 만드는 tcp_v4_syn_recv_sock()은 요청 소켓의 IP 옵션(ireq_opt)을 복사하지 않고 넘겨준다. 그런데 이 시점에 재전송된 SYN에 대한 SYNACK 생성이 동시에 일어나면, ip_options_build()가 이미 해제된 메모리를 읽을 수 있다(use-after-free). 요청 소켓 마이그레이션(net.ipv4.tcp_migrate_req=1) 경로에서도 같은 일이 생긴다. 수정은 inet_sock_destruct()와 tcp_v4_reqsk_destructor()에서 이 옵션을 kfree_rcu()로 해제하도록 바꾼 것이다. 이렇게 하면 동시에 읽고 있는 쪽이 끝날 때까지 해제가 미뤄진다. 업스트림 커밋은 e3f33b0a1d89다. IPv6는 첫 번째 경로의 영향을 받지 않는다 (Ubuntu CVE JSON). 자세한 원리는 10/29 글에 있다.

정리

수정 커널은 나왔다. 하지만 “나왔다”와 “내 서버에서 돌고 있다” 사이에는 세 개의 틈이 있다. 첫째, pocket이다. 자동 갱신이 집어 가는 길에 그 커널이 있는가. 둘째, flavour다. 내가 쓰는 커널이 고쳐진 그 패키지인가, 아직 -proposed인 HWE인가. 셋째, 재부팅이다. 깔린 커널이 실제로 돌고 있는가. 이 셋을 각각 확인해야 끝난 것이다.

References

  1. Ubuntu Security, CVE-2026-98432 (CVE 데이터, 2026-11-10 17:01 UTC 갱신) — https://ubuntu.com/security/CVE-2026-98432 / JSON
  2. Canonical (Luci Stanescu), Fixes available for CVE-2026-98432 (2026-11-02 게시, 11-09 갱신) — https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432
  3. CVE Program, CVE-2026-98432 — https://www.cve.org/CVERecord?id=CVE-2026-98432
  4. Linux kernel, upstream fix commit e3f33b0a1d89 — https://git.kernel.org/linus/e3f33b0a1d89d738e2b913dab519226eaf76e15b
  5. Launchpad API, getPublishedSources (ubuntu primary archive; linux, linux-hwe-6.8, linux-hwe-7.0, 2026-11-11 조회) — https://api.launchpad.net/devel/ubuntu/+archive/primary
  6. Ubuntu Server documentation, Automatic updates — https://documentation.ubuntu.com/server/how-to/software/automatic-updates/