Ubuntu NVIDIA 커널 USN-9003-1: 재부팅 필수

Ubuntu NVIDIA 커널 USN-9003-1은 Ubuntu 26.04·24.04 LTS의 특정 커널 패키지를 업데이트하고 재부팅해야 하는 보안 공지다. NVIDIA 그래픽 드라이버만 바꾸는 작업이 아니다. Ubuntu가 배포하는 NVIDIA systems·NVIDIA BaseOS용 리눅스 커널을 쓰는 서버가 대상이다.[1]

GPU가 달린 Ubuntu 서버라면 모두 해당하나?

GPU 유무가 아니라 설치된 커널 패키지로 판단해야 한다. 공지의 패키지는 linux-nvidia-7.0(NVIDIA systems용 커널)과 linux-nvidia-bos(NVIDIA BaseOS systems용 커널)다. NVIDIA의 .run 설치 파일이나 nvidia-driver 패키지만을 고치는 공지가 아니다.[1]

일반 linux-generic만 사용하는 웹서버에 이 공지의 커널 패키지가 설치돼 있다고 단정하면 안 된다. 반대로 NVIDIA 시스템용 커널을 운영한다면 GPU 드라이버 버전 확인만으로 이번 점검을 끝내서도 안 된다. 해당 여부를 알아보기 위해 커널 종류를 임의로 바꿀 필요도 없다.

USN-9003-1의 공개일은 2026년 11월 6일이다. 공지 HTML에는 공개 시·분이 표시되지 않는다. 릴리스와 수정 패키지 표에는 Ubuntu 26.04 LTS(resolute)와 24.04 LTS(noble)가 나온다. 다른 릴리스가 표에 없다고 해서 그 릴리스의 모든 커널이 안전하다는 뜻은 아니다.[1]

어느 버전을 확인하면 되나?

설치한 이미지 패키지와 같은 행의 수정 버전을 대조하면 된다. 아래는 공식 표의 대표 예다. 전체 표에는 메타패키지와 64k 변형도 있으므로 자기 서버의 패키지명을 기준으로 확인해야 한다.[1]

26.04 표에는 linux-image-nvidia-bos와 linux-image-nvidia-hwe-26.04, 24.04 표에는 linux-image-nvidia-7.0과 linux-image-nvidia-hwe-24.04 등이 함께 실려 있다.[1] 이름이 비슷하더라도 다른 릴리스나 다른 커널 계열의 버전 숫자를 서로 비교하면 안 된다.

패키지 버전과 실행 중인 커널 버전도 구분해야 한다. uname -r은 현재 부팅한 커널의 릴리스 문자열을 보여준다. 표의 .23이나 .25~24.04.1까지 포함한 전체 패키지 버전을 보여주는 명령은 아니다. 설치 버전 대조와 재부팅 후 실행 커널 확인은 별도 점검이다.

업데이트 전에 어떤 명령으로 대상을 가리나?

현재 실행 커널과 설치된 NVIDIA 계열 커널 이미지 목록을 함께 확인한다. 다음 명령은 USN에 실린 전용 명령이 아니라, 관리자가 대상 패키지를 찾기 위한 실무 보조 명령이다. 조회만 하며 패키지를 설치하거나 바꾸지 않는다.

uname -r

dpkg -l \
  'linux-image-nvidia*' \
  'linux-image-*-nvidia*' \
  2>/dev/null | grep -E '^ii'

dpkg -l 결과에서는 ii로 표시된 설치 항목의 패키지명과 버전을 본다. 설치된 옛 커널이 남아 있을 수도 있으므로 목록에 이름이 있다는 사실만으로 그 커널로 부팅했다고 판단하지 않는다. 출력이 없으면 이 이름 패턴에 맞는 설치 항목이 없다는 범위로 읽고, 현재 실행 커널과 서버의 패키지 구성을 다시 확인한다.

저장소가 제공하는 메타패키지 버전은 아래처럼 확인할 수 있다. 모든 이름이 한 서버에 설치돼 있어야 한다는 뜻은 아니다. 사용 중인 릴리스에 맞는 항목의 Installed와 Candidate를 구분해 본다.

apt-cache policy \
  linux-image-nvidia-hwe-24.04 \
  linux-image-nvidia-hwe-26.04 \
  linux-image-nvidia-bos \
  linux-image-nvidia-7.0 \
  2>/dev/null

PM 작업표에는 호스트명, Ubuntu 릴리스, 커널 계열, 설치 버전, 실행 커널을 따로 적어 두면 좋다. 같은 Ubuntu 서버라도 웹서버와 가속기 호스트의 커널 구성이 다를 수 있다. Ubuntu nginx ESM 패치 점검도 서비스 이름만 보지 않고 릴리스와 패키지 버전을 먼저 가리는 작업이다.

표준 업데이트만 끝나면 패치가 적용되나?

아니다. Canonical은 표준 시스템 업데이트 뒤 필요한 변경을 모두 적용하려면 재부팅해야 한다고 명시한다.[1] 패키지 설치 성공과 새 커널로 부팅한 상태는 다르다.

대상 호스트를 확인한 뒤 유지보수 시간과 재부팅 담당자를 정한다. 작업 중인 GPU 연산, 서비스의 다른 노드 전환, 접속 복구 수단은 환경에 맞춰 먼저 확인한다. 이는 운영상 준비 사항이지 이번 USN이 별도 명령으로 요구한 절차는 아니다.

sudo apt update는 패키지 목록을 새로 받는 단계일 뿐 보안 패키지 설치를 끝내는 명령이 아니다. 이후 조직에서 사용하는 표준 시스템 업그레이드 절차로 대상 커널의 갱신을 마치고 설치 오류가 없는지 확인한다. 그다음 정해 둔 시간에 재부팅한다. GPU 드라이버만 따로 올리거나 다른 커널 계열을 억지로 설치하는 방식으로 대체하지 않는다.

패키지 관리자 자체의 보안 상태를 별도로 점검해야 한다면 APT CVE-2026-109518 수정 버전 안내를 참고할 수 있다. APT 업데이트와 이번 커널 업데이트는 서로 다른 패키지의 조치다.

ABI가 바뀌면 외부 모듈은 어떻게 하나?

새 커널에 맞춰 서드파티 커널 모듈을 다시 컴파일하고 설치해야 한다. ABI는 커널과 모듈이 서로 연결되는 방식이다. 공지는 불가피한 ABI 변경 때문에 새 커널 버전 번호를 부여했으며, 사용자가 설치한 서드파티 모듈의 재컴파일·재설치가 필요하다고 안내한다.[1]

직접 빌드한 드라이버나 별도 공급업체가 제공한 모니터링 모듈이 있다면 작업 목록에 포함한다. DKMS를 쓰는 환경에서는 재빌드 결과와 오류 로그를 확인한다. DKMS 점검은 실무 보조 사항이며, 모든 외부 모듈이 자동으로 복구된다고 보장하는 말은 아니다.

공지는 표준 커널 메타패키지를 수동으로 제거하지 않았다면 표준 시스템 업그레이드가 이 과정도 자동으로 수행한다고 설명한다.[1] 다만 직접 설치한 외부 모듈까지 확인 없이 정상이라고 처리해서는 안 된다. 업그레이드 중 빌드 실패가 있었다면 먼저 해결하고, 재부팅 후 필요한 모듈과 서비스가 정상인지 확인한다.

어떤 취약점이 포함됐고 실제 악용도 확인됐나?

커널의 여러 영역에 대한 수정이며, 아래는 그중 일부 사례다. 직접 확인한 USN과 네 개 Ubuntu CVE 페이지에서는 현재 악용 중이라는 설명을 확인하지 못했다. 그렇다고 악용이 불가능하거나 다른 곳에도 보고가 없다는 뜻은 아니다.[1][2][3][4][5]

• CVE-2023-20585 — Ubuntu 우선순위 Low. 일부 AMD 프로세서에서 IOMMU가 특정 호스트 버퍼에 접근할 때 RMP 검사를 제대로 하지 않는 문제다. 하이퍼바이저 접근권이 있는 로컬 공격자가 SEV-SNP 게스트 메모리의 무결성을 훼손할 수 있다는 조건부 설명이다. 모든 GPU 서버가 곧바로 원격 침해된다는 의미가 아니다.[1][2]
• CVE-2026-80879 — Ubuntu 우선순위 Medium. OCFS2 파일시스템의 ocfs2_dio_end_io_write에서 발생하는 순환 잠금 의존성을 수정한다. 이 잠금 문제만으로 다른 공격 효과까지 단정할 수는 없다.[3]
• CVE-2026-80880 — Ubuntu 우선순위 Medium. InfiniBand의 IB/mlx5에서 implicit ODP 메모리 영역 재등록 처리를 바로잡는 수정이다.[4]
• CVE-2026-89774 — Ubuntu 우선순위 Medium, CVSS v3 8.8 High. Bluetooth SCO의 sco_conn_ready에서 소켓 참조를 제대로 유지하지 않아 동시 종료 시 해제된 메모리에 접근할 수 있는 문제다. Ubuntu의 처리 우선순위와 CVSS 심각도 표기는 다른 지표이므로 함께 구분해서 본다.[5]

이름에 NVIDIA가 들어가도 수정 범위는 GPU 드라이버 한 부분에 한정되지 않는다. 공지에는 IOMMU, Netfilter, KVM, AppArmor, NVME, InfiniBand, Bluetooth 등 여러 커널 하위 영역이 나열돼 있다.[1] 개별 취약점을 전부 원격 코드 실행으로 묶어 설명할 근거는 없다.

Jetson·Tegra 장비도 같은 표를 쓰면 되나?

Tegra 계열은 별도 공지 USN-9002-1도 확인해야 한다. 같은 날 나온 이 공지는 Ubuntu 24.04 LTS의 linux-nvidia-tegra 커널을 다루며, io_uring의 취소 작업 처리와 관련한 CVE-2026-81010 등 수정과 재부팅·ABI 변경 주의를 안내한다. Jetson·Tegra 장비라면 실제 설치 패키지를 확인하고 해당 공지를 따로 대조하자. USN-9003-1의 버전 표를 그대로 옮겨 적용하지 않는다.[6]

재부팅 뒤에는 무엇을 확인하고 작업을 닫나?

수정 패키지 설치, 새 커널 실행, 필요한 모듈과 서비스의 정상 동작을 각각 확인하고 마무리한다. 재부팅 이후 다시 uname -r로 실행 커널을 보고, 패키지 조회 결과는 자기 릴리스의 공식 수정 버전과 별도로 대조한다.

• 대상 이미지와 메타패키지의 설치 결과에 오류가 없는지 확인한다.
• 설치된 새 커널이 아니라 이전 커널로 부팅한 것은 아닌지 확인한다.
• 직접 설치한 외부 모듈의 재빌드·로드 결과와 필요한 서비스의 상태를 확인한다.
• PM 기록에 재부팅 시각, 실행 커널, 패키지 버전, 서비스 확인 결과를 남긴다.

버전 확인 중 다른 공지의 시험 배포 패키지와 혼동하지 않도록 주의하자. 이전 Ubuntu 커널의 정식 배포 전 상태를 다룬 글과 이번 USN은 서로 다른 안내다. 이번 작업의 기준은 USN-9003-1의 대상 패키지와 수정 버전 표다.[1]

종료 기준은 “업데이트 명령을 실행했다”가 아니다. 해당 호스트의 커널 패키지를 갱신하고 재부팅한 뒤, 새 커널과 외부 모듈로 서비스가 정상 동작하는지 확인하는 데까지다.

출처