🇰🇷 한글 설명
Linux 커널의 idpf 드라이버에서 DIM(Dynamic Interrupt Moderation) 작업이 메모리 해제 전에 적절히 중단되지 않는 취약점이 발견되었습니다. 이로 인해 이미 해제된 메모리 영역에 접근하여 ITR 레지스터를 쓰려고 시도하는 Use-After-Free 오류가 발생할 수 있습니다.
💡 쉬운 설명
컴퓨터가 사용 중인 메모리를 다 썼다고 판단해 버렸는데, 다른 작업이 여전히 그 메모리를 사용하려고 시도하면서 발생하는 오류입니다. 이 과정에서 시스템이 충돌하거나 예상치 못한 동작을 할 수 있습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
idpf: disable DIM work before freeing q_vectors
idpf never drains the Tx/Rx DIM works before freeing the memory they
live in. tx_dim and rx_dim are embedded in struct idpf_q_vector, they
are queued from the NAPI poll via net_dim(), and idpf_vport_intr_rel()
ends with kfree(rsrc->q_vectors). Nothing in the driver cancels them.
idpf_tx_dim_work() and idpf_rx_dim_work() then run on freed memory:
idpf_vport_intr_write_itr() writes the ITR register through
q_vector->intr_reg.tx_itr / rx_itr, void __iomem pointers loaded out of
the freed q_vector. No configuration is needed to get there --
IDPF_ITR_IS_DYNAMIC() is defined as (itr_mode) and idpf_vport_alloc()
initialises both modes to IDPF_ITR_DYNAMIC.
Draining after idpf_vport_intr_napi_dis_all() is not enough on its own.
idpf_net_dim() is called from inside the
"if (napi_complete_done(napi, work_done))" branch of the poll, and
napi_complete_done() has already cleared NAPIF_STATE_SCHED by then.
napi_disable_locked() waits only while (val & (NAPIF_STATE_SCHED |
NAPIF_STATE_NPSVC)), so napi_disable() can return while the poll tail is
still queueing the work, and a plain cancel_work_sync() would be
re-armed behind the drain.
Use disable_work_sync(): schedule_work() on a work with a non-zero
disable count is dropped by clear_pending_if_disabled() before
__queue_work() is reached.
Move idpf_init_dim() to idpf_vport_intr_alloc() so the works are
initialised on every path that can reach the drain -- the three
"goto intr_deinit" sites between idpf_vport_intr_init() and
idpf_vport_intr_ena() get there without the enable side having run.
Nothing re-enables them: rsrc->q_vectors is freed on every exit from
idpf_vport_open() and on every idpf_vport_stop(), so the count dies with
the object.
It is a race, not a deterministic failure -- net_dim() only schedules
once DIM_NEVENTS events have accumulated and the profile index changes.
A KASAN ifup/ifdown loop under load is the way to see it.
📍 영향받는 시스템
Linux kernel (idpf driver 포함 버전)
⚔️ 공격 벡터
네트워크 부하가 높은 상태에서 인터페이스를 반복적으로 켜고 끄는(ifup/ifdown) 레이스 컨디션 유도
🛡️ 대응 방법
idpf 드라이버의 DIM 작업 처리 로직이 수정된 최신 Linux 커널로 업데이트
🔧 검증 코드
출력된 커널 버전이 해당 취약점이 패치된 최신 보안 업데이트 버전인지 확인합니다.