🇰🇷 한글 설명
Linux 커널의 KEYS 서브시스템에서 add_key() 호출 시 keyring 제한(restriction) 설정과의 경쟁 조건(race condition)이 발견되어 수정되었습니다. 제한 정책을 읽는 시점이 잘못되어, 키링 소유자가 모든 링크를 거부하도록 설정한 후에도 쓰기 권한이 있는 사용자가 키를 추가할 수 있었습니다.
💡 쉬운 설명
여러 사람이 동시에 보안 금고에 물건을 넣는 상황에서, 금고 주인이 '아무것도 넣지 마라'고 막 설정했는데도 일부 물건이 몰래 들어갈 수 있는 문제입니다. 제한 확인 시점을 바로잡아 이를 막았습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
KEYS: Fix add_key() race with keyring restriction
__key_create_or_update() snapshots keyring->restrict_link before taking
the destination keyring's semaphore. keyring_restrict() installs a
restriction while holding that semaphore.
This allows a writer to observe no restriction, wait for the keyring
owner to install a reject-all restriction and return successfully, and
then link a key using the stale NULL snapshot. The writer only needs
write permission on the destination keyring.
Move the restrict_link read after __key_link_lock() and
__key_link_begin(). The read and the subsequent restriction check are
then serialized with restriction installation by keyring->sem.
The race was reproduced on v7.2.8 in 19 executions where restriction
installation returned before the link completed. All 19 linked the key
despite the reject-all restriction. With this change, 312 executions
reached the same ordering and every add_key() call failed with -EPERM.
The issue was found by manual concurrency analysis assisted by AI-based
analysis and independently verified with a QEMU reproducer and kernel
instrumentation.
📍 영향받는 시스템
수정 전 Linux 커널 (v7.2.x 등 해당 패치 이전 버전)을 사용하는 시스템
⚔️ 공격 벡터
키링에 쓰기 권한을 가진 로컬 사용자가 키링 제한 설정과 동시에 add_key()를 호출해 제한을 우회하여 키를 등록
🛡️ 대응 방법
배포판 제공 최신 Linux 커널로 업데이트 후 재부팅
🔧 검증 코드
출력된 커널 버전을 확인하여 해당 수정 패치가 포함된 최신 버전인지 배포판 보안 공지와 대조하세요.