CVE-2026-90001 in Linux
요약
\~에 의해 VulDB • 2026. 09. 16.
Linux 커널에서 다음 취약점이 해결되었습니다:
HID: bpf - struct_ops destroy 경로에서 디바이스 참조 해제 직렬화
__hid_bpf_ops_destroy_device()와 hid_bpf_unreg()는 동일한 등록 참조(registration reference)를 놓고 Race Condition을 일으켜, struct hid_device에 대해 이중으로 put 수행(double-putting)하고 hid_destroy_device()가 여전히 이를 사용하는 동안 해지(freeing)할 수 있습니다. hdev->bpf.prog_list_lock 하에서 제거/NULL 결정을 직렬화하여 각 등록 참조를 정확히 하나의 경로에서만 해제하도록 합니다: unreg는 잠금(lock) 내에서 ops->hdev를 재확인하며, destroy 경로가 이미 이를 지운 경우 put 없이 반환합니다; 모든 put_device() 호출은 잠금이 해제된 후에 발생하므로 안전합니다. 이는 동시(unreg) 실행 시 잠금 하에서 ops->hdev == NULL을 관찰하기 때문입니다.
배경: 각 성공적인 attach(hid_bpf_ops_reg)는 하나의 디바이스 참조(hid_get_device())를 획득합니다. 이를 해제할 수 있는 두 가지 경로가 있습니다:
- 디바이스 파괴: hid_destroy_device() -> hid_bpf_destroy_device() -> __hid_bpf_ops_destroy_device(). 이는 rcu_read_lock() 하에서 hdev->bpf.prog_list를 순회하며 연결된 각 프로그램당 하나의 참조를 해제합니다. - BPF 링크 릴리스: bpf 맵 삭제(BPF_F_LINK 없음)는 동기적으로 st_ops->unreg() -> hid_bpf_unreg()를 호출하여 자체 등록에 대한 참조를 해제합니다.
조정 핸드셰이크(destroy 측에서 e->hdev = NULL vs unreg 측에서 "if (!hdev) return")는 TOCTOU(Time-of-Check to Time-of-Use) 검사입니다: 두 경로는 서로 다른 잠금 도메인(rcu_read_lock 대 prog_list_lock) 하에서 실행되므로, 동시(unreg)가 ops->hdev를 NULL이 아닌 것으로 읽은 후 prog_list_lock을 기다리다가 destroy 순회가 실행되는 동안 계속 진행할 수 있습니다. 이 경우 두 경로 모두 동일한 참조를 해제하게 됩니다. refcount는 합법적으로 0에 도달합니다(각 감소는 개별적으로 유효함). 따라서 refcount_t 포화(refcount saturation)가 발생하지 않습니다: 디바이스는 여전히 hid_destroy_device() 내부에 있는 동안 단순히 해지되며, 이후의 정리(teardown) 과정에서 이미 해지된 메모리에 접근하게 됩니다.
해결책은 양쪽에서 prog_list_lock 하에서 제거/NULL 결정을 직렬화하고 destroy 측의 puts를 잠금 외부로 이동합니다. 잠금을 유지한 상태에서 ops->hdev에 대한 일반 읽기/쓰기가 충분하므로, READ_ONCE/WRITE_ONCE는 추가되지 않아 패치를 최소화했습니다.
잠금 없는(read) 읽기 안전성: hid_bpf_unreg() 상단에서 수행되는 ops->hdev의 잠금 없는(unlocked) 읽기는 해지된 디바이스에 접근할 수 없습니다. 이는 unreg 경로 자체가 해당 등록에 대한 참조를 여전히 보유하고 있기 때문입니다(이 참조는 잠금이 해제된 후 자체 hid_put_device()로만 해제됨). 또한 이미 ops->hdev를 지운 destroy 순회는 잠금 내부의 재확인 시 조기에 반환하여 put을 수행하지 않습니다. 두 경로 중 최대 하나만이 각 등록 참조를 해제합니다.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.