🇰🇷 한글 설명
Linux 커널의 BPF 구현에서 RCU 트레이싱 중 특정 객체들이 free_by_rcu_ttrace 상태에 갇혀 해제되지 않는 메모리 누수 취약점이 발견되었습니다. 이로 인해 해제되지 않는 객체의 수가 제한 없이 증가할 수 있어 시스템 자원 고갈을 초래할 수 있습니다.
💡 쉬운 설명
컴퓨터의 메모리를 정리하는 과정에서 일부 데이터가 삭제되지 않고 계속 쌓이는 버그가 발생했습니다. 이 문제가 방치되면 메모리가 가득 차서 시스템이 느려지거나 멈출 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix objects stuck in free_by_rcu_ttrace
do_call_rcu_ttrace() returns early when call_rcu_ttrace_in_progress is set
and leaves the objects in free_by_rcu_ttrace. __free_rcu() frees
waiting_for_gp_ttrace only and clears the flag. Hence the objects that
free_bulk() or __free_by_rcu() added while RCU tasks trace GP was in flight
stay in free_by_rcu_ttrace until free_bulk() or alloc_bulk() is called for
the same bpf_mem_cache again, which may never happen. The number of such
objects is not bounded.
Turn call_rcu_ttrace_in_progress into three states:
0 - idle
1 - __free_rcu() is queued
2 - __free_rcu() is queued and free_by_rcu_ttrace got more objects since
do_call_rcu_ttrace() sets 2. __free_rcu() does cmpxchg(1 -> 0) and starts
the next GP when it fails. It cannot clear the flag first and check
free_by_rcu_ttrace later, since bpf_mem_alloc_destroy() frees bpf_mem_cache
without waiting for RCU callbacks when the flag is zero.
Now __free_rcu() queues itself, so the one that didn't see 'draining' may
do call_rcu_tasks_trace() after rcu_barrier_tasks_trace() in
free_mem_alloc(). Queue it under rcu_read_lock() and do synchronize_rcu()
before the barriers. Calling rcu_barrier_tasks_trace() twice works too, but
creating and destroying hash maps in a loop on many cpus slows down to one
free_mem_alloc() per GP and kworkers pile up.
📍 영향받는 시스템
Linux kernel (BPF subsystem using RCU tracing)
⚔️ 공격 벡터
로컬 공격자가 BPF 해시 맵을 반복적으로 생성 및 삭제하여 메모리 누수를 유도할 수 있음
🛡️ 대응 방법
해당 취약점이 수정된 최신 버전의 Linux 커널로 업데이트하십시오.
🔧 검증 코드
출력된 커널 버전이 취약점이 패치된 최신 릴리스 버전인지 확인하십시오.