주진 이2026년 10월, Linux 커널의 IPv4 TCP 네트워크 처리 과정에서 원격 코드 실행(Remote Code Execution, RCE)으로 이어질 수 있는 심각한 보안 취약점 CVE-2026-98432가 공개되었습니다.
이번 취약점은 Linux 커널이 TCP 연결 요청을 처리하는 과정에서 발생하는 경쟁 상태(Race Condition)와 메모리 해제 시점의 문제로 인해 발생합니다.
특히 공격자가 서버에 직접 로그인하거나 별도의 인증 과정을 거치지 않고도 취약한 네트워크 처리 경로를 악용할 가능성이 있다는 점에서 주의가 필요합니다.
Red Hat은 해당 취약점을 Critical 등급으로 분류하고 CVSS v3.1 기준 9.8점을 부여했으며, RHEL 8·9·10을 포함한 여러 제품군에 대한 보안 대응을 안내하고 있습니다.
이번 글에서는 CVE-2026-98432의 발생 원리와 Linux 커널 내부의 메모리 관리 구조를 살펴보고, RHEL 및 Rocky Linux 환경에서 취약점 영향을 확인하고 대응하는 방법을 알아보겠습니다.
1. CVE-2026-98432 취약점 개요
CVE-2026-98432는 Linux 커널의 IPv4 네트워크 서브시스템에서 발견된 Use-After-Free(UAF) 취약점입니다.
Use-After-Free는 메모리가 해제된 이후에도 해당 메모리를 참조하는 문제가 발생하는 메모리 안전성 취약점입니다.
이번 취약점에서는 여러 CPU가 TCP 연결 요청을 동시에 처리하는 과정에서 소켓 옵션 데이터가 해제된 뒤에도 다른 실행 경로에서 참조될 수 있습니다.
취약점 주요 정보
| 항목 | 내용 |
| CVE 번호 | CVE-2026-98432 |
| 공개일 | 2026년 10월 15일 |
| Red Hat 보안 공지 | RHSB-2026-016 |
| Red Hat 위험도 | Critical |
| CVSS v3.1 | 9.8 |
| 취약점 유형 | Use-After-Free |
| 주요 발생 영역 | Linux Kernel IPv4 TCP |
| 공격 조건 | 원격 접근 가능, 인증 불필요 |
| 잠재적 영향 | 서비스 거부, 커널 메모리 손상, 원격 코드 실행 |
이번 취약점은 TCP 연결을 수신하는 Linux 서버에서 중요하게 검토해야 합니다.
특히 웹서버, 데이터베이스 서버, 애플리케이션 서버처럼 외부 또는 내부 네트워크에서 TCP 연결 요청을 처리하는 시스템은 노출 경로와 커널 패치 상태를 확인해야 합니다.
다만 TCP 포트가 열려 있다는 이유만으로 모든 서버가 취약한 것은 아닙니다. 실제 영향 여부는 사용 중인 커널과 배포판의 보안 패치 적용 상태에 따라 달라집니다.
2. Linux 커널에서 취약점이 발생하는 원리
이번 취약점을 이해하려면 Linux 커널의 TCP 연결 요청 처리 구조를 살펴볼 필요가 있습니다.
2.1 TCP 연결 수립과 Request Socket
TCP 연결은 일반적으로 다음과 같은 3-Way Handshake 과정을 거쳐 수립됩니다.
- 클라이언트가 서버로 SYN 패킷을 전송합니다.
- 서버는 SYN-ACK 패킷으로 응답합니다.
- 클라이언트가 ACK 패킷을 전송하면 연결이 수립됩니다.
Linux 커널은 이러한 연결 수립 과정에서 Request Socket이라는 내부 자료구조를 사용합니다.
Request Socket은 연결이 완전히 수립되기 전의 상태와 관련 정보를 관리하는 데 사용됩니다.
이 과정에서 IPv4 옵션 정보가 저장될 수 있으며, 연결 수립 이후 생성되는 Child Socket으로 해당 옵션 데이터의 소유권이 이전될 수 있습니다.
문제는 이러한 소유권 이전과 메모리 해제가 여러 CPU에서 동시에 이루어질 때 발생할 수 있다는 점입니다.
2.2 Race Condition과 Use-After-Free
Linux 커널은 여러 CPU에서 네트워크 패킷을 병렬로 처리할 수 있습니다.
이때 동일한 연결 요청과 관련된 작업이 서로 다른 CPU에서 동시에 수행될 수 있습니다.
예를 들어 다음과 같은 상황을 생각할 수 있습니다.
CPU 1
- TCP 연결 요청을 처리합니다.
- Request Socket의 IPv4 옵션 데이터 소유권을 Child Socket으로 이전합니다.
- 이후 소켓이 해제되면서 관련 옵션 메모리도 해제될 수 있습니다.
CPU 2
- 같은 연결 요청에 대한 재전송 SYN을 처리합니다.
- SYN-ACK 응답을 생성하는 과정에서 IPv4 옵션 데이터를 참조합니다.
- CPU 1에서 이미 해제한 메모리에 접근할 수 있습니다.
이러한 상황을 Race Condition이라고 합니다.
두 실행 경로의 처리 순서에 따라 정상적으로 동작할 수도 있지만, 특정 시점에 메모리가 먼저 해제되면 Use-After-Free가 발생할 수 있습니다.
해제된 메모리는 다른 커널 객체에 재사용될 수 있으므로 단순한 접근 오류를 넘어 메모리 손상이나 커널 충돌로 이어질 가능성이 있습니다.
2.3 취약점과 관련된 주요 커널 함수
Linux Kernel CVE Team에서 공개한 기술 설명에는 다음 함수들이 등장합니다.
| 커널 함수 | 주요 역할 |
|---|---|
tcp_v4_syn_recv_sock() |
TCP 연결 수립 과정에서 Child Socket 생성 |
tcp_check_req() |
수신된 연결 요청 및 상태 확인 |
tcp_v4_send_synack() |
IPv4 SYN-ACK 응답 전송 |
inet_csk_route_req() |
연결 요청의 라우팅 정보 처리 |
ip_options_build() |
IPv4 옵션 정보 처리 |
inet_sock_destruct() |
소켓 객체 정리 |
tcp_v4_reqsk_destructor() |
Request Socket 관련 자원 정리 |
이번 문제의 핵심은 일부 코드가 IPv4 옵션 데이터를 RCU 읽기 보호 구간에서 참조하고 있었지만, 메모리를 해제하는 경로에서는 일반적인 kfree()가 사용되었다는 점입니다.
또한 Request Socket Migration 과정에서도 유사한 메모리 수명 관리 문제가 존재했습니다.
3. RCU와 커널 메모리 해제 방식
이번 취약점에 적용된 수정 사항을 이해하려면 RCU(Read-Copy-Update)의 개념을 알아야 합니다.
RCU는 Linux 커널에서 여러 실행 경로가 공유 데이터에 접근할 때 사용되는 동기화 메커니즘입니다.
특히 읽기 작업이 빈번한 환경에서 동시성을 높이는 데 활용됩니다.
3.1 기존 메모리 해제 방식
기존 취약 코드의 메모리 해제 경로에서는 kfree()가 사용되었습니다.
kfree()는 동적으로 할당한 커널 메모리를 해제하는 함수입니다.
그러나 다른 CPU가 RCU 읽기 구간에서 해당 메모리를 참조하고 있다면, 일반적인 메모리 해제 방식만으로는 참조 중인 데이터의 수명을 보장하기 어렵습니다.
3.2 수정된 메모리 해제 방식
이번 보안 수정에서는 관련 메모리 해제 경로에 kfree_rcu()를 사용하도록 변경했습니다.
kfree_rcu()는 RCU Grace Period가 지난 이후 메모리를 해제하도록 처리합니다.
RCU Grace Period는 기존에 시작된 관련 RCU 읽기 구간이 종료되었음을 보장할 수 있는 기간을 의미합니다.
이를 통해 다른 CPU가 데이터를 참조하고 있는 동안 해당 메모리가 조기에 해제되는 문제를 방지합니다.
즉, 이번 취약점의 핵심 수정 사항은 단순한 입력값 검증이 아니라 공유 메모리의 수명 관리 방식을 수정하여 동시성 문제를 해결하는 것입니다.
Linux 커널에서는 고성능 네트워크 처리를 위해 병렬성과 동시성을 적극 활용하므로, 이러한 메모리 수명 관리가 시스템 안정성과 보안에 중요한 영향을 미칩니다.
4. 취약점 영향 범위 및 대상 운영체제
이번 취약점은 특정 웹서버나 애플리케이션 패키지에서 발생한 문제가 아니라 Linux 커널의 네트워크 처리 계층에서 발견되었습니다.
따라서 동일한 취약 코드가 포함된 커널을 사용하는 여러 Linux 배포판이 영향을 받을 수 있습니다.
주요 운영체제별 영향 현황
| 운영체제 | 확인 사항 |
|---|---|
| RHEL 8 | Red Hat 공식 영향 대상 |
| RHEL 9 | Red Hat 공식 영향 대상 |
| RHEL 10 | Red Hat 공식 영향 대상 |
| Rocky Linux 8 | 사용 중인 커널 및 보안 공지 확인 필요 |
| Rocky Linux 9 | 관련 보안 수정 공지 확인 |
| Rocky Linux 10 | 관련 보안 수정 공지 확인 |
| Amazon Linux 2 / 2023 | 관련 보안 업데이트 제공 |
| Ubuntu / Debian | 각 배포판의 공식 보안 추적 정보 확인 필요 |
| OpenShift | 기반 커널 영향 대상, 별도 공식 대응 지침 확인 필요 |
Linux Kernel CVE Team은 해당 취약점이 커널 4.4에서 도입되었다고 설명하고 있습니다.
공개된 업스트림 수정 버전에는 6.12.113, 6.18.56, 7.2.10 등이 포함됩니다.
하지만 이 정보만으로 RHEL이나 Rocky Linux 서버의 취약 여부를 판단해서는 안 됩니다.
배포판 커널의 Backport 정책
RHEL 계열 운영체제는 일반적으로 안정적인 커널 버전을 유지하면서 보안 수정 사항을 기존 커널에 반영하는 Backport 방식을 사용합니다.
따라서 동일한 기본 커널 버전이라도 배포판의 패키지 릴리스에 따라 보안 패치 적용 여부가 달라질 수 있습니다.
예를 들어 커널 버전이 4.18.0으로 시작한다는 이유만으로 취약하다고 단정할 수 없습니다.
정확한 판단을 위해서는 다음 사항을 함께 확인해야 합니다.
- 현재 실행 중인 커널의 전체 버전
- 설치된 커널 패키지 버전
- 배포판에서 제공하는 CVE 보안 권고
- 해당 취약점 수정 패키지의 설치 여부
5. Linux 서버 취약점 점검 방법
실제 서버 환경에서는 무조건 커널 업데이트부터 진행하기보다 현재 상태를 확인하고 영향 범위를 파악해야 합니다.
아래 절차는 RHEL 및 Rocky Linux의 DNF 기반 환경을 기준으로 작성했습니다.
5.1 사전 조회: 변경 전 기준값 확인
운영체제 정보, 커널 버전, 보안 업데이트 정보 및 네트워크 서비스 상태를 함께 확인합니다.
cat /etc/os-release
uname -r
rpm -q kernel kernel-core
grubby --default-kernel
grubby --info=ALL
dnf updateinfo info --available --cve CVE-2026-98432
dnf list --available kernel kernel-core
df -h /boot
ss -lnt
uname -r은 현재 실제 실행 중인 커널 버전을 출력합니다.
rpm -q는 설치된 커널 패키지를 확인하는 데 사용합니다.
dnf updateinfo는 활성화된 저장소에서 해당 CVE와 관련된 보안 권고 정보를 확인합니다.
ss -lnt는 서버가 수신 대기 중인 TCP 포트를 확인합니다. 다만 포트 정보는 네트워크 노출 범위를 판단하기 위한 참고 자료이며, 취약점 패치 여부를 판정하는 명령은 아닙니다.
또한 저장소에서 CVE 검색 결과가 나타나지 않는다고 해서 해당 서버가 안전하다는 의미는 아닙니다.
저장소 설정, 보안 메타데이터 제공 여부, 업데이트 반영 시점 등에 따라 조회 결과가 달라질 수 있기 때문입니다.
5.2 변경 전 백업 및 복구 준비
커널 업데이트 작업에서는 일반 설정 파일 수정과 달리 커널 패키지가 새로 설치됩니다.
따라서 특정 설정 파일을 복사하는 것만으로 커널 업데이트의 복구를 보장할 수 없습니다.
작업 전에는 현재 설치된 커널 버전과 부팅 항목을 기록하고, 기존 커널이 보존되는지 확인해야 합니다.
가상화 환경에서는 운영 정책에 따라 VM 백업 또는 스냅샷을 검토할 수 있습니다.
단, 스냅샷은 모든 환경에서 애플리케이션 데이터의 일관성을 보장하는 것은 아니므로 기존 백업 정책을 대체하지 않습니다.
5.3 영향도 확인
커널 업데이트 후 새로운 커널을 적용하려면 일반적으로 서버 재부팅이 필요합니다.
재부팅이 발생하면 운영 중인 서비스 및 네트워크 연결이 중단될 수 있습니다.
따라서 실제 변경 전 다음 항목을 검토해야 합니다.
- 웹서버, 데이터베이스 등 핵심 서비스 중단 영향
- 물리 서버 및 가상머신의 콘솔 접근 가능 여부
- 신규 커널과 스토리지·네트워크 드라이버의 호환성
- HA 및 클러스터 환경의 노드별 재부팅 순서
- 기존 커널로 재부팅할 수 있는 복구 경로
특히 원격 IDC 서버에서는 SSH 접속이 불가능해지는 상황에 대비하여 별도의 원격 콘솔 또는 하이퍼바이저 콘솔 접근 수단을 확보하는 것이 중요합니다.
6. 커널 보안 패치 적용 방법
6.1 커널 업데이트
공식 저장소에서 해당 취약점에 대한 수정 패키지 제공 여부를 확인한 뒤 커널 업데이트를 진행합니다.
RHEL 및 Rocky Linux 환경에서는 다음과 같이 업데이트할 수 있습니다.
sudo dnf update kernel위 명령은 설치된 커널 패키지를 저장소에서 제공하는 업데이트 버전으로 갱신합니다.
다만 실제 취약점 수정 여부는 해당 배포판의 보안 권고와 설치되는 패키지 버전을 대조해야 합니다.
업데이트 전 변경되는 패키지 및 의존성 목록을 확인한 뒤 작업을 승인해야 합니다.
6.2 서버 재부팅
커널 패키지 업데이트가 완료되더라도 현재 메모리에서 실행 중인 커널이 자동으로 변경되지는 않습니다.
신규 커널을 실제로 적용하려면 재부팅이 필요합니다.
sudo reboot
운영 서버에서는 서비스 점검 시간과 재부팅 후 복구 절차를 사전에 협의한 뒤 수행해야 합니다.
7. 커널 업데이트 실패 시 복구 방법
커널 업데이트 후 정상적으로 부팅되지 않거나 드라이버 호환성 문제가 발생하는 경우 기존 커널로 부팅하는 방법을 검토할 수 있습니다.
먼저 변경 전 확인한 커널 및 부팅 항목 정보를 기준으로 이전 커널이 시스템에 남아 있는지 확인해야 합니다.
기존 커널이 보존되어 있고 부팅 가능한 상태라면 GRUB 부팅 메뉴 또는 grubby를 활용하여 이전 커널을 선택할 수 있습니다.
예를 들어 기존 커널 부팅 이미지의 전체 경로가 확인된 경우 다음과 같이 기본 부팅 커널을 지정할 수 있습니다.
sudo grubby --set-default /boot/vmlinuz-기존커널전체버전
sudo reboot
위 명령의 기존커널전체버전은 실제 서버에 존재하는 이전 커널 버전으로 변경해야 합니다.
단, 이전 커널로 부팅하는 것은 서비스 복구를 위한 조치이며, 취약한 커널로 돌아갈 경우 보안 위험이 다시 존재할 수 있습니다.
따라서 복구 이후에도 네트워크 접근 제한과 패치 재적용 계획을 검토해야 합니다.
8. 업데이트 후 검증 방법
재부팅이 완료되면 변경 전 수집한 기준값과 비교하여 업데이트 결과를 검증합니다.
uname -r
rpm -q kernel kernel-core
grubby --default-kernel
systemctl --failed
journalctl -k -b -p err --no-pager
검증 시 확인해야 할 핵심 항목은 다음과 같습니다.
커널 적용 여부
uname -r에서 출력되는 커널 버전이 업데이트된 보안 수정 패키지와 일치하는지 확인합니다.
서비스 상태
systemctl --failed 결과를 변경 전 서비스 상태 및 운영 시스템의 정상 상태와 비교합니다.
커널 로그
journalctl을 이용하여 현재 부팅 이후 발생한 커널 오류를 확인합니다.
실제 서비스 동작
웹서비스, 데이터베이스, 애플리케이션 등 재부팅 영향을 받는 주요 서비스의 정상 동작 여부를 확인합니다.
서비스 기능 검증은 각 운영 환경에서 사전에 정한 헬스체크 및 접속 테스트 기준에 따라 수행해야 합니다.
최종적으로 보안 권고에서 안내하는 수정 패키지가 적용되었는지 확인하면 커널 취약점 대응 결과를 판단할 수 있습니다.
9. 커널 패치를 즉시 적용하기 어려운 경우
모든 운영 환경에서 보안 패치를 즉시 적용할 수 있는 것은 아닙니다.
특히 무중단 운영이 요구되는 서버나 정해진 유지보수 시간에만 재부팅할 수 있는 시스템에서는 임시 보안 완화 조치가 필요할 수 있습니다.
Red Hat은 CVE-2026-98432에 대한 임시 대응책으로 IPv4 옵션이 포함된 인바운드 TCP 패킷을 nftables로 필터링하는 방법을 안내하고 있습니다.
이 방식은 취약점 악용에 필요한 일부 패킷이 커널의 관련 처리 경로에 도달하지 못하도록 제한합니다.
일반적인 TCP 옵션과 IPv4 헤더의 IP 옵션은 서로 다르므로, 해당 필터링 규칙은 IPv4 헤더 길이를 기준으로 동작합니다.
다만 이러한 조치는 정상적인 IPv4 옵션 사용 트래픽에도 영향을 줄 수 있습니다.
또한 Red Hat은 해당 필터링이 취약점을 완전히 해결하는 것은 아니라고 명시하고 있습니다.
따라서 운영 환경에서는 네트워크 구성과 업무 영향도를 검토한 후 비운영 환경에서 먼저 검증해야 합니다.
주의할 점은 MPTCP를 비활성화하는 것만으로 이번 취약점이 해결되지 않는다는 사실입니다.
해당 취약점은 일반 IPv4 TCP 연결 처리 과정에서도 발생할 수 있기 때문입니다.
임시 완화 조치는 어디까지나 패치 전까지의 위험을 줄이기 위한 수단이며, 근본적인 해결 방법은 공식 보안 업데이트가 적용된 커널을 설치하고 실제 실행 커널에 반영하는 것입니다.
10. 운영 환경에서의 보안 대응 방향
이번 CVE-2026-98432 사례는 Linux 커널의 취약점이 단순한 패키지 수준의 문제가 아니라 네트워크 서비스 전체의 안정성과 보안에 영향을 줄 수 있음을 보여줍니다.
특히 인증 없이 접근할 수 있는 네트워크 처리 경로에서 발생한 취약점은 외부 노출 여부와 공격 조건을 함께 고려해야 합니다.
기업의 Linux 서버 운영 환경에서는 다음 사항이 중요합니다.
- 공식 보안 권고를 기준으로 영향 대상 시스템을 식별합니다.
- 배포판별 보안 패치 제공 여부를 확인합니다.
- 변경 전 커널 및 부팅 정보를 확보하고 복구 가능성을 검토합니다.
- 서비스 중단 영향을 고려하여 업데이트 일정을 수립합니다.
- 신규 커널 적용 후 정상 부팅과 서비스 동작을 검증합니다.
- 패치를 즉시 적용할 수 없는 시스템은 공식 임시 완화 조치를 검토합니다.
특히 커널 보안 패치는 패키지 설치 성공만으로 작업을 완료했다고 판단해서는 안 됩니다.
실제 실행 중인 커널에 수정 사항이 반영되었는지 확인하는 과정까지 포함해야 합니다.
11. 마무리
CVE-2026-98432는 Linux 커널의 IPv4 TCP 연결 처리 과정에서 발생하는 Use-After-Free 취약점입니다.
이번 취약점의 핵심은 여러 CPU가 동시에 네트워크 요청을 처리하는 과정에서 공유 메모리의 수명이 적절하게 관리되지 않았다는 점입니다.
이를 해결하기 위해 커널에서는 kfree_rcu()를 활용한 메모리 해제 방식이 적용되었습니다.
RHEL 및 Rocky Linux를 운영하는 환경에서는 단순히 커널 버전 번호만 확인하기보다 공식 보안 권고와 수정 패키지 적용 여부를 함께 검토해야 합니다.
또한 커널 업데이트에는 재부팅이 수반될 수 있으므로 서비스 영향도와 복구 방안을 사전에 준비해야 합니다.
운영 서버의 보안 대응은 취약점 확인, 패치 적용, 재부팅 및 검증까지 완료되었을 때 비로소 마무리할 수 있습니다.
참고 자료
Red Hat 보안 공지 — CVE-2026-98432