🇰🇷 한글 설명
Linux 커널의 bnxt 네트워크 드라이버에서 IRQ 어피니티 노티파이어를 취소할 때 데드락(교착 상태)이 발생할 수 있는 취약점입니다. 노티파이어 콜백 내에서 네트워크 장치 인스턴스 잠금을 획득한 상태로 작업을 취소하려 시도하여 발생하는 문제입니다. 이를 해결하기 위해 큐 재시작 작업을 비동기 서비스 태스크로 이동하여 잠금 충돌을 방지했습니다.
💡 쉬운 설명
네트워크 장치의 설정이 변경될 때 시스템이 서로의 자원을 기다리며 멈춰버리는 현상이 발생할 수 있습니다. 이로 인해 시스템이 응답하지 않거나 먹통이 될 위험이 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
eth: bnxt: avoid deadlock when canceling IRQ affinity notifier
Unregistering IRQ affinity notifiers waits for the callback synchronously.
bnxt takes the netdev instance lock in the notifier (to restart the queue)
and cancels the work under the same lock. This may obviously deadlock.
Move the restart to the async service task. The queue restart isn't
super time sensitive. Store the new TPH tag, schedule the task.
Safely canceling the service task is already ironed out.
In bnxt_request_irq() the order of registering notifier, affinity and
initial TPH programming has to be inverted. I think it was racy
previously since user may trigger an update as soon as notifier
is installed.
There's a small known gap - if pcie_tph_get_cpu_st() fails at init
and the target tag is 0 we may miss programming the entry.
This does not seem worth fixing, the code has skip-on-failure
all over the place, anyway.
📍 영향받는 시스템
Linux kernel (bnxt driver 사용 시스템)
⚔️ 공격 벡터
로컬 사용자가 IRQ 어피니티 설정을 빈번하게 변경하거나 특정 네트워크 드라이버 조작을 통해 데드락 유도 가능
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하십시오.
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 해결된 패치 버전 이후인지 확인하십시오.