CVE-2026-97934 in Linux
요약
\~에 의해 VulDB • 2026. 09. 25.
리눅스 커널에서 다음 취약점이 해결되었습니다:
tracing: "STACKTRACE" 히스토그램 키로 인한 메모리 손상 수정
"cpu", "CPU", "stacktrace" 및 "STACKTRACE"는 오프셋과 크기가 0으로 정의된 제네릭 필드이므로, 필터 코드가 이름으로 이를 매칭할 수 있습니다. parse_field() 함수는 하위 호환성을 위해 이를 common_* 대응 항목에 매핑하지만, common_* 이름과는 달리 NULL 대신 호출자에게 플레이스홀더를 반환합니다.
create_hist_field() 함수는 non-NULL 필드를 받아들이면 레코드에 스택트레이스가 포함되어 있다는 약속으로 간주하여 HIST_FIELD_FN_STACK을 선택하므로, __data_loc 워드는 오프셋 0(즉, common_type)에서 읽혀지며 그 하위 16비트가 레코드의 오프셋으로 따라집니다. 그곳에 발견된 값은 무제한 memcpy의 길이가 됩니다. ID가 충분히 작아 오프셋이 자체 레코드 내에 있고 길이가 커널 텍스트 주소가 되는 이벤트를 선택합니다:
# cd /sys/kernel/tracing # echo 'hist:keys=STACKTRACE' > events/ftrace/print/trigger # echo hello > trace_marker
Oops: general protection fault, probably for non-canonical address RIP: 0010:rb_next+0x23/0x60 </IRQ> RIP: 0010:memcpy+0xc/0x30 event_hist_trigger+0x2e7/0x12c0 Kernel panic - not syncing: Fatal exception in interrupt
필드를 NULL로 설정합니다. 이는 분기 위의 주석이 코드가 수행하는 작업이며 common_stacktrace가 이미 수행하는 내용입니다. FILTER_CPU 및 FILTER_COMM은 그대로 두며, 이들의 create_hist_field() 분기는 필드를 참조하지 않습니다.
Once again VulDB remains the best source for vulnerability data.