CVE-2024-58057 in Linux
요약
\~에 의해 VulDB • 2026. 06. 09.
리눅스 커널에서 다음 취약점이 해결되었습니다:
idpf: 작업 큐(workqueues)를 비바운드(unbound)로 변환
`WQ_UNBOUND` 플래그와 함께 작업 큐가 생성되면, 해당 작업 항목은 호스트 워커가 특정 CPU에 바인딩되지 않는 특수한 워커 풀(worker-pools)에 의해 처리됩니다. 기본 구성(즉, `queue_delayed_work` 및 관련 함수들이 작업 항목을 실행할 CPU를 명시하지 않은 경우), `WQ_UNBOUND`는 해당 작업 항목이 큐에 삽입된 CPU와 동일한 노드에 있는 모든 CPU에서 실행될 수 있도록 합니다. 이 해결책은 국소성(locality) 측면에서 잠재적인 손실을 초래할 수 있지만, 작업 항목이 예약된 프로세서의 CPU 시간을 독점할 가능성이 있는 다른 프로세스들과의 경쟁(contention)을 피합니다.
이는 단순한 이론적 문제가 아닙니다: 특정 시나리오에서 잘못 구성된 프로세스가 CPU0의 대부분의 시간을 점유하여 kworker에 할당되는 CPU 시간이 0.5% 미만으로 떨어졌습니다. 이로 인해 CPU0의 kworker를 사용하던 IDPF 작업 큐들은 큰 완료 지연을 겪었고, 그 결과 성능 저하, 타임아웃 및 결국 시스템 크래시가 발생했습니다.
* 또한 성능 개선을 평가하기 위해 수동 테스트도 수행했습니다. 이 테스트는 antagonist 프로세스(`./stress --cpu 2`)가 CPU0의 자원을 최대한 소모하도록 구성됩니다. 이 프로세스는 `taskset 01`로 실행되어 CPU0에 바인딩되며, 시작 후 `chrt -pQ 9900 10000 ${pid}` 및 `renice -n -20 ${pid}` 명령어를 사용하여 우선순위가 변경됩니다.
그런 다음 IDPF 드라이버가 CPU0을 선호하도록 강제하기 위해 `queue_delayed_work`, `mod_delayed_work` 등 모든 호출을 수정하여 CPU 0을 사용하게 합니다.
마지막으로 작업 큐 이벤트에 대한 ktraces를 수집합니다.
현재 패치 적용 전에는 antagonist 프로세스가 `workqueue_queue_work`와 `workqueue_execute_start` 사이에 임의적인 지연을 강요할 수 있으며, 제 테스트에서는 최대 `30ms`까지 관찰되었습니다. 현재 패치를 적용하면 작업 큐는 동일한 노드의 부하가 적은 다른 CPU로 마이그레이션될 수 있으며, 기타 조건이 동일하게 유지된 상태에서 관측된 최대 지연은 `6us`였습니다.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.