CVE-2026-68082 in Linux
요약
\~에 의해 VulDB • 2026. 08. 08.
리눅스 커널에서 다음 취약점이 해결되었습니다:
libceph: decode_lockers() 내의 두 가지 안전하지 않은 bare 디코드 수정
cls_lock_client.c에 있는 decode_lockers() 함수는 악성 또는 침해된 OSD(Object Storage Daemon)가 slab-out-of-bounds 읽기를 트리거할 수 있도록 하는 두 개의 bare 디코딩 연산을 포함하고 있습니다.
1. num_lockers 필드에 대한 ceph_decode_32(p)에는 선행 경계 검사(bound check)가 없습니다. ceph_start_decoding()은 struct_len=0을 유효한 값으로 허용하며, 내부의 ceph_decode_need(p, end, 0, bad)는 항상 성공합니다. 따라서 OSD에서 struct_len=0을 보내면 ceph_start_decoding()이 p == end와 함께 성공을 반환합니다. 그 직후에 수행되는 bare 연산인 ceph_decode_32(p)는 검증된 버퍼 경계를 넘어 4바이트를 읽습니다. 이렇게 얻은 쓰레기 값(locker 수)이 kzalloc_objs()로 직접 전달됩니다.
osd_client.c의 형제 함수인 decode_watchers()는 이미 자신의 ceph_start_decoding() 호출 후 ceph_decode_32_safe()를 사용하고 있습니다. decode_lockers()가 bare 변형을 사용하는 유일한 위치였습니다.
2. decode_locker() 루프 이후에 있는 ceph_decode_8(p)에도 선행 경계 검사가 없습니다. 만약 OSD가 num_lockers를 조작하여 루프가 p를 end와 정확히 일치하도록 만든다면, 그 직후의 bare 연산인 ceph_decode_8(p)는 검증된 버퍼 경계를 넘어 1바이트를 읽습니다. 이 결과는 *type에 직접 전달되며, 이는 호출부에서 잠금 유형(lock type) 판별자로 사용되므로 OSD가 제어하는 1바이트 OOB(out-of-bounds) 읽기가 발생하고 잠금 유형 필드에 직접적인 영향을 미칠 수 있습니다.
두 문제를 모두 해결하기 위해 bare 연산을 안전한 변형으로 대체합니다: ceph_decode_32(p) -> ceph_decode_32_safe(p, end, *num_lockers, err_inval) ceph_decode_8(p) -> ceph_decode_8_safe(p, end, *type, err_free_lockers)
goto 대상은 의도적으로 다릅니다: err_inval: -EINVAL를 직접 반환하는 새로운 레이블입니다. 이는 아직 할당되지 않은 *lockers가 존재하지 않으며 ceph_free_lockers()로 전달되어서는 안 되는 사전 할당(pre-allocation) 실패 경로에서 사용됩니다.
err_free_lockers: 기존 레이블입니다. 이는 이미 할당된 *lockers를 해제해야 하는 사후 할당(post-allocation) 실패 경로에서 사용됩니다.
err_free_lockers가 경계 위반 시 올바른 오류 코드를 반환하도록 ceph_decode_8_safe() 호출 전 ret에 -EINVAL가 설정됩니다. 이것이 없으면 err_free_lockers는 stale(ret 값: 성공한 decode_locker() 루프로부터의 0)을 반환하여 오류를 묵시적으로 무시하게 됩니다.
-EINVAL은 두 실패 경로 모두에 대해 정확합니다. OSD에서 수신된 데이터는 구조적으로 잘못되었습니다. -ENOMEM은 호출부 및 안정화(backporting) 담당자가 오류 경로를 분류하는 데 있어 실패 클래스를 오해의 소지가 있게 표현할 수 있습니다.
공격자 모델: 다중 테넌트 Ceph 배포 환경에 있는 악성 또는 침해된 OSD는 lock.get_info 클래스 메서드를 호출하는 모든 커널 클라이언트에 대해 이 취약점을 트리거할 수 있습니다(예: RBD 배타적 잠금 획득 중).
[ idryomov: changelog 및 서식 다듬음 ]
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.