CVE-2026-74513 in Linux
요약
\~에 의해 VulDB • 2026. 08. 15.
리눅스 커널에서 다음 취약점이 해결되었습니다:
dibs: 루프백 attach/detach/unregister 시 dmb_node의 use-after-free 수정
dibs_lo_attach_dmb(), dibs_lo_detach_dmb() 및 dibs_lo_unregister_dmb() 함수는 dmb_ht_lock 하위에서 dmb_node를 조회한 후, 잠금을 해제하고 나서야 노드의 refcount에 대한 작업을 수행합니다. 해당 시간 창(window) 동안 노드가 살아있는 상태를 유지하는 것을 보장하지 않습니다: __dibs_lo_unregister_dmb()은 쓰기 락(write lock) 하에서 해시 테이블에서 노드를 제거하고 즉시 메모리를 해제(free)합니다.
따라서 동시 실행되는 마지막 put 연산으로 인해 조회와 refcount 작업 사이에 노드가 해제될 수 있습니다:
CPU0 (attach) CPU1 (소유자가 unregister 수행)
read_lock_bh(&dmb_ht_lock) find dmb_node (refcnt == 1) read_unlock_bh(&dmb_ht_lock) refcount_dec_and_test() 1 -> 0 write_lock_bh(&dmb_ht_lock) hash_del(&dmb_node->list) write_unlock_bh(&dmb_ht_lock) kfree(dmb_node) refcount_inc_not_zero(&dmb_node->refcnt) <-- use-after-free
detach 및 unregister 경로에서 refcount_dec_and_test() 호출에도 동일한 시간 창이 존재합니다.
해시 테이블 멤버십과 refcount 전이가 서로에 대해 원자적(atomic)이 되도록 구조적으로 race condition을 해결합니다:
- unregister와 detach 경로 모두에서, 마지막 refcount_dec_and_test() 및 hash_del() 연산을 단일 dmb_ht_lock 쓰기 측 임계 섹션(write-side critical section) 내에서 수행합니다. 노드 해제는 여전히 잠금이 해제된 후에 발생하지만, 이는 안전합니다. 왜냐하면 refcount가 0에 도달한 노드는 이미 해시 테이블에서 제거되었으며 더 이상 검색될 수 없기 때문입니다.
- 이를 통해 해시 테이블에서 발견되는 모든 노드가 최소 하나의 참조(reference)를 보유하며, 마지막 참조는 오직 쓰기 락 하에서만 해제된다는 불변식(invariant)이 확립됩니다. 따라서 dibs_lo_attach_dmb()은 읽기 락(read lock)을 유지한 상태에서 일반 refcount_inc()로 자신의 참조를 획득할 수 있으며, 더 이상 refcount_inc_not_zero()가 필요하지 않습니다.
__dibs_lo_unregister_dmb()는 이제 해시 테이블에 접근하지 않으며, 이에 따라 dibs_lo_free_dmb()로 이름이 변경되었습니다.
참고: 커밋 cc21191b584c("dibs: Move data path to dibs layer")은 코드를 현재 위치로 이동시켰으며, race condition은 이전에 commit c3a910f2380f("net/smc: implement DMB-merged operations of loopback-ism")에 의해 도입되었습니다.
ISM 및 dibs 루프백을 통해 SMC-D를 테스트했습니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.