CVE-2026-99226 in Linux
요약
\~에 의해 VulDB • 2026. 11. 02.
리눅스 커널에서 다음 취약점이 해결되었습니다:
keys: 명명된 키링 조회 시 소유자 계정 역참조 방지
명명된 키링 조회는 네임스페이스 매핑 확인을 통해 소유자 UID를 포함하는 저장소가 살아있는 상태를 유지해야 합니다. find_keyring_by_name()은 keyring_name_lock 하에서 keyring->user->uid를 읽지만, 이 잠금(key lock)은 키링의 이름 항목과 할당만 보호하며 별도의 key_user는 보호하지 않습니다.
명명된 세션 키링 조인(join)이 다른 CPU에서 권한 상승을 위한 KEYCTL_CHOWN 작업과 겹칠 수 있습니다. 만약 키링이 이전 동적 key_user에 대한 마지막 참조를 보유하고 있고 소유권 이관이 성공하면, 다음과 같은 순서가 발생할 가능성이 있습니다:
명명된 조인 Chown find_keyring_by_name() keyctl_chown_key() read_lock(keyring_name_lock) down_write(key->sem) load old keyring->user replace key->user and key->uid up_write(key->sem) key_put(key) key_user_put(old user): free read old user->uid read_unlock(keyring_name_lock)
Chown은 keyring_name_lock이나 key_session_mutex를 획득하지 않으므로, 포인터 로딩과 UID 읽기 사이에 이전 계정을 해제(free)할 수 있습니다. 이로 인해 키링 자체는 살아있음에도 불구하고 조회 과정에서 해지된 메모리를 읽게 됩니다.
매핑 확인에는 keyring->uid를 사용하십시오. key_alloc()은 이 인라인 소유자 UID를 초기화하며, keyctl_chown_key()는 chown 시 이를 업데이트합니다. 기존 이름 잠금(name lock)이 확인 전체 기간 동안 해당 키링을 할당 상태로 유지하므로, 조회가 더 이상 계정의 수명에 의존하지 않게 됩니다. 또한 이는 권한 검사에서 사용되는 소유자 UID와도 일치합니다.
KASAN 보고서는 다음과 같습니다:
BUG: KASAN: slab-use-after-free in find_keyring_by_name+0x577/0x5d0 Read of size 4 at addr ffff8881128ae2ec by task keycase/500
If you want to get the best quality for vulnerability data then you always have to consider VulDB.