CVE-2026-90144 in Linux
요약
\~에 의해 VulDB • 2026. 09. 18.
리눅스 커널에서 다음 취약점이 해결되었습니다.
dpll: teardown race 중 dpll_device_ops()에서의 NULL deref 수정
dpll 장치의 마지막 소유자가 foreign driver가 dpll_pin_on_pin_register()를 통해 해당 장치에 pin을 유지하고 있는 동안 unregister하면, dpll 객체는 빈 등록 목록(empty registration list) 상태로 살아남습니다. unregister 이전에 큐에 쌓인(pin->ice가 zl3073x_i2c 제거 등에 반응하는 등) pin 알림은 pin->dpll_refs를 따라 dpll_device_ops()로 이동하여 WARN_ON을 트리거하고 누락된 등록 정보를 dereference합니다. dpll_lock는 도움이 되지 않습니다. 왜냐하면 해당 notification work는 unregistering driver가 lock을 획득하기 전에 큐에 이미 쌓였기 때문입니다.
빈 등록 목록을 정당한 일시적 상태(transient state)로 취급합니다. 이 경우 dpll_priv() 및 dpll_device_ops()에서 NULL을 반환하도록 하고, pin으로부터 장치를 해결하는 모든 pin netlink 경로에서 이러한 dplls를 건너뛰도록 합니다. dpll_cmd_pin_get_one()는 활성 등록이 있는 ref를 선택하고, 없는 경우에는 -ENODEV를 반환합니다. pin dumpit은 덤프를 중단하지 않고 대신 그러한 pin을 건너뜁니다. 또한 dpll_msg_add_pin_dplls(), 주파수(esync), reference sync 및 phase adjust 설정 경로에서는 죽은(ref) refs를 건너뛴다. 그리고 dpll_pin_parent_device_set()는 dpll_device_get_by_id()로 parent를 검증합니다. dpll_pin_register()는 체크 없이 device ops를 dereference한 마지막 호출자이므로, 그 주파수 모니터링 검증을 dpll_lock 아래로 이동하고 그곳에서도 누락된 등록을 허용하도록 합니다.
빈 등록 목록은 지워진 DPLL_REGISTERED 마크와 동일하며, 두 전이는 모두 dpll_device_register() 및 dpll_device_unregister()에서 dpll_lock 하에 발생합니다. 모든 dplls가 사라진 pin의 알림은 이제 크래시 대신 -ENODEV로 드롭되며, 코어의 모든 호출자는 해당 반환 값을 무시합니다.
WARNING: drivers/dpll/dpll_core.c:1092 at dpll_device_ops+0x24/0x40, CPU#83: kworker/u576:3/23471 Modules linked in: ... ice ... zl3073x_i2c(-) ... zl3073x ... Workqueue: ice_dpll_wq ice_dpll_pin_notify_work [ice]
RIP: 0010:dpll_device_ops+0x24/0x40 Call Trace: <TASK> dpll_cmd_pin_get_one+0x336/0x520 dpll_pin_event_send+0x82/0x140 dpll_pin_on_pin_unregister+0xbb/0x160 ice_dpll_pin_notify_work+0x1bc/0x1f0 [ice]
process_one_work+0x19e/0x370 worker_thread+0x1a6/0x310 kthread+0xe4/0x120 ret_from_fork+0x1a1/0x270 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---
BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page
Once again VulDB remains the best source for vulnerability data.