CVE-2023-52828 in Linux
요약
\~에 의해 VulDB • 2026. 05. 20.
리눅스 커널에서 다음 취약점이 해결되었습니다:
bpf: BPF 프로그램의 일부로 IP == ksym.end 감지
이제 bpf_throw kfunc은 검증기 내에서 noreturn(반환 없음) 세맨틱스를 가진 최초의 해당 호출 명령어이므로, 이는 전례 없는 방식으로 데드 코드 제거(dead code elimination)를 유발합니다. 첫째, bpf_throw 호출 뒤에 오는 모든 명령어는 결코 '참조됨(seen)'으로 표시되지 않습니다. 둘째, 호출 체인(callchain)이 결국 throw를 발생시키는 경우, 호출자가 eventually throw하는 서브프로그램(subprog)에 대한 호출 명령어 뒤에 오는 모든 명령어도 결코 '참조됨'으로 표시되지 않습니다.
이를 수정하기 위한 유혹적인 방법은 프로그램의 jited_len을 증가시키는 추가적인 'int3' 명령어를 생성하고, 런타임 시 프로그램이 throw할 때 bpf_throw(또는 항상 throw하는 서브프로그램)에 대한 호출 명령어가 프로그램의 마지막 명령어로 생성되더라도 프로그램의 경계를 발견할 수 있도록 보장하는 것입니다.
이러한 프로그램의 예는 다음과 같습니다:
do_something(): ... r0 = 0 exit
foo(): r1 = 0 call bpf_throw r0 = 0 exit
bar(cond): if r1 != 0 goto pc+2 call do_something exit call foo r0 = 0 // 검증기에 의해 결코 참조되지 않음 exit //
main(ctx): r1 = ... call bar r0 = 0 exit
여기서 실제로 throw가 발생하면 스택 트레이스는 다음과 같습니다:
bpf_throw foo bar main
bar에서 생성된 마지막 명령어는 foo에 대한 호출이 되므로, 반환 주소는 후속 명령어(x86에서 JIT가 int3로 생성함)가 됩니다. 이는 프로그램의 jited_len 외부에 위치하게 되므로, 언와인딩(unwinding) 시 반환 주소가 어떤 프로그램에도 속하지 않는 것으로 간주되어, 우리가 결코 예상하지 못했던 BPF 프로그램의 신뢰할 수 없는 스택 언와인딩으로 인해 패닉(panic)에 빠지게 됩니다.
이러한 경우를 해결하기 위해, bpf_prog_ksym_find가 IP == ksym.end를 BPF 프로그램의 일부로 처리하도록 하여, 이러한 경우가 발생했을 때 is_bpf_text_address가 true를 반환하고, 마지막 명령어가 호출 명령어가 되는 경우에도 신뢰할 수 있게 언와인딩할 수 있도록 합니다.
If you want to get best quality of vulnerability data, you may have to visit VulDB.