CVE-2024-14040 in Linux
요약
\~에 의해 VulDB • 2026. 07. 26.
리눅스 커널에서 다음 취약점이 해결되었습니다:
net: nexthop: 가중치를 u16로 증가시킴
CLOS 네트워크에서는 링크 장애가 네트워크의 다양한 지점에서 발생할 때, 관련 노드의 ECMP(Equal-Cost Multi-Path) 가중치가 이를 보정하기 위해 조정됩니다. 관련 노드의 높은 팬아웃(fan-out)과 전체적인 많은 수의 노드로 인해 구성하고자 하는 (비)ECMP 가중치 비율이 8비트에 맞지 않을 수 있습니다. 예를 들어, 255:254 대신 1000:999와 같은 값을 구성하고 싶을 수 있으며, 이러한 배포 환경에서는 8비트 가중치가 충분하지 않을 수 있습니다.
이를 위해 이 패치에서 다음 홉(next hop) 가중치를 u8에서 u16로 증가시킵니다.
정수 타입의 너비를 늘리는 것은 까다로운 작업일 수 있는데, 코드가 여전히 컴파일되더라도 타입 검사에 문제가 생기고 수치 오류가 발생할 수 있기 때문입니다. 이를 방지하기 위해 변환은 두 단계로 수행되었습니다. 먼저 타입을 u8에서 단일 멤버 구조체로 변경하여 필드의 모든 사용을 무효화했습니다. 이렇게 하면 하나씩 검토하며 타입 정확성을 감사(audit)할 수 있었습니다. 그런 다음 해당 구조체를 다시 일반적인(u16) u16으로 교체했습니다. 이를 통해 누락된 곳이 없음을 보장합니다.
nexthop 그룹 멤버를 구성하기 위한 UAPI는 NHA_GROUP 속성이 struct nexthop_grp 엔트리의 배열을 운반한다는 것입니다:
struct nexthop_grp {
__u32 id; /* nexthop id - 반드시 존재해야 함 */ __u8 weight; /* 이 nexthop의 가중치 */ __u8 resvd1; __u16 resvd2; };
현재 resvd1 필드는 유효성 검사가 수행되며 0이어야 합니다. 우리는 이 요구사항을 해제하고 예약된 필드에 가중치의 상위 비트를 담을 수 있습니다:
struct nexthop_grp {
__u32 id; /* nexthop id - 반드시 존재해야 함 */ __u8 weight; /* 이 nexthop의 가중치 */ __u8 weight_high; __u16 resvd2; };
기존 사용자 공간(userspace)에서 weight 필드의 너비에 대한 가정(assumptions)을 하고 있을 수 있고, 엔디안(endianness) 문제를 피하기 위해 이러한 방식으로 필드를 분리해 두기로 했습니다.
현재 weight 필드는 가중치 값에서 1을 뺀 값으로 인코딩됩니다. 이는 가중치가 0인 것은 유효하지 않기 때문입니다. 새로운 weight_high 필드에 대해서는 이 트릭(기법)이 불가능합니다. 왜냐하면 0은 실제 0을 의미해야 하기 때문입니다. 이를 적용할 때:
- 기존 사용자 공간에서는 weight_high가 항상 0으로 운반되므로, 적절한 경우 8비트 가중치를 구성하게 됩니다. 16비트 가중치를 가진 nexthops를 덤프(dumping)할 때는 하위 8비트만 표시됩니다. 그러나 이러한 nexthops를 구성한다는 것은 근본적으로 확장에 대한 인식이 있는 사용자 공간이 존재함을 암시합니다.
- 구형 커널과 통신하는 신규 사용자 공간은 상위 비트가 0인 경우에만 8비트 가중치를 구성하려고 시도한다면 정상 작동할 것입니다. 구형 커널은 >8비트 가중치 구성 시도를 거부(bounce)합니다.
예약된 필드를 어떤 목적으로 할당되었는지 알 수 있는 이름으로 변경하는 것은 리눅스에서 흔히 이루어지는 작업입니다. 예약된 필드에 접근하는 사람은 자신의 책임 하에 그렇게 해야 합니다. 특히 nexthop_grp::resvd1은 현재 적어도 strace에서 사용되고 있지만, 그들은 자체적인 UAPI 헤더 사본을 보유하고 있으므로 변환은 trivial(단순)해야 합니다. 두 필드로부터 가중치를 디코딩하기 위한 헬퍼(helper)가 제공됩니다. 역호환성(backwards compatibility)을 위해 익명 공용체(anonymous unions) 등을 도입하는 것보다 강제로 변환하는 것이 더 선호
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.