CVE-2026-64352 in Linux
요약
\~에 의해 VulDB • 2026. 07. 25.
리눅스 커널에서 다음 취약점이 해결되었습니다:
bpf: 수면 가능(sleepable) BPF 프로그램에서 LPM 맵 접근 허용
trie_lookup_elem()은 rcu_dereference_check() 순회를 수행할 때 rcu_read_lock_bh_held() 어노테이션만 사용합니다. rcu_dereference_check(p, c)는 "c || rcu_read_lock_held()"로 해석되므로, 이는 XDP/NAPI 및 클래식 RCU 리더에게는 통과하지만 __bpf_prog_enter_sleepable()을 통해 진입하고 rcu_read_lock_trace()만 보유하는 수면 가능 BPF 프로그램에서는 실패합니다.
trie_update_elem()과 trie_delete_elem()도 다른 형태의 동일한 문제를 가지고 있습니다: 이들은 plain rcu_dereference()로 트리를 순회하며, 이는 조건 없이 rcu_read_lock_held()를 어서션(assert)합니다. 둘 다 bpf_map_update_elem / bpf_map_delete_elem 헬퍼를 통해 수면 가능 BPF 프로그램에서 접근 가능하며, 클래식 rcu_read_lock() 하의 시스템 콜 경로에서도 접근 가능합니다. 작성자(writer) 경로의 트리는 실제로 trie->lock(순회 전체에 걸쳐 획득되는 rqspinlock)으로 보호됩니다; 우리는 해당 노드가 살아있도록 유지하기 위해 RCU 읽기 전용(lock-side) 잠금을 전혀 의존하지 않았습니다.
따라서 LPM 트리에 접촉하는 수면 가능 LSM 후크는 디버그 커널에서 lockdep를 트리거합니다:
============================= WARNING: suspicious RCU usage 7.1.0-... Tainted: G E ----------------------------- kernel/bpf/lpm_trie.c:249 suspicious rcu_dereference_check() usage! 1 lock held by net_tests/540: #0: (rcu_tasks_trace_srcu_struct){....}-{0:0},
at: __bpf_prog_enter_sleepable+0x26/0x280 Call Trace: dump_stack_lvl lockdep_rcu_suspicious trie_lookup_elem bpf_prog_..._enforce_security_socket_connect bpf_trampoline_... security_socket_connect __sys_connect do_syscall_64
이는 lockdep 전용 문제입니다 -- Tasks Trace RCU가 트리의 회수(reclaim) 경로에 대해 직렬화를 수행하므로 UAF(Use-After-Free)는 발생하지 않습니다. -- 하지만 LPM 트리에 접촉하는 수면 가능 BPF LSM을 실행하는 모든 디버그 커널에서 고유한 호출 사이트마다 콘솔이 스팸처럼 채워집니다. 이는 점점 더 흔해지고 있는 상황입니다.
조회 경로(lookup path)의 경우, rcu_dereference_check() 어노테이션을 rcu_read_lock_bh_held()에서 bpf_rcu_lock_held()로 전환합니다. 이는 세 가지 컨텍스트(클래식, BH, Tasks Trace) 모두를 허용합니다. 다른 맵 타입들은 이미 이 관례를 따르고 있습니다.
trie_update_elem()과 trie_delete_elem()의 경우, 순회 동안 trie->lock이 보유되므로 rcu_dereference_protected(*p, 1)로 어노테이션합니다(동일 파일 내 trie_free()와 일치). rqspinlock은 lockdep_map을 가지지 않으므로 술어(predicate)는 '1'로 단순화되며 lockdep_is_held(&trie->lock)가 되지 않습니다. 보호는 실제적이지만 기계적으로 검증 가능하지는 않습니다. trie_get_next_key()도 bare rcu-dereference를 사용하지만, 이는 BPF 시스템 콜에서만 접근 가능하며, 여기서 클래식 rcu_read_lock()이 디스패치 전에 보유되므로 변경되지 않고 그대로 유지됩니다.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.