CVE-2026-90144 in Linux
Résumé
par VulDB • 17/09/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
dpll : correction d'une déréférencement NULL dans dpll_device_ops() lors d'une condition de concurrence (race condition) au moment du désamorçage.
Lorsque le dernier propriétaire d'un périphérique DPLL se désenregistre alors qu'un pilote tiers détient encore un verrouillage sur celui-ci via dpll_pin_on_pin_register(), l'objet DPLL reste en vie avec une liste d'enregistrement vide. Une notification de verrouillage (pin) mise en file d'attente avant la désinscription (par exemple, ice réagissant au retrait de zl3073x_i2c) parcourt ensuite pin->dpll_refs vers dpll_device_ops(), ce qui déclenche le WARN_ON et déréférence l'enregistrement manquant. La fonction dpll_lock ne peut pas aider car la tâche de notification a été mise en file d'attente avant que le pilote se désenregistrant n'ait pris le verrouillage (lock).
Considérez la liste d'enregistrement vide comme un état transitoire légitime. Faites en sorte que dpll_priv() et dpll_device_ops() retournent NULL dans ce cas, et faites en sorte que chaque chemin netlink de pin qui résout un périphérique à partir d'un pin ignore ces DPLL. La fonction dpll_cmd_pin_get_one() sélectionne une référence avec un enregistrement actif et retourne -ENODEV lorsqu'il n'y en a pas ; la fonction dumpit pour les pins ignore ce type de pin au lieu d'interrompre le vidage (dump) ; dpll_msg_add_pin_dplls(), ainsi que les chemins de réglage de fréquence, esync, synchronisation des références et ajustement de phase ignorent les références mortes ; et dpll_pin_parent_device_set() valide le parent avec dpll_device_get_by_id(). La fonction dpll_pin_register() est le dernier appelant qui déréférençait les opérations du périphérique sans vérification ; son validation de surveillance de fréquence a donc été déplacée sous dpll_lock, tolérant également un enregistrement manquant à cet endroit.
La liste d'enregistrement vide équivaut à une marque DPLL_REGISTERED effacée ; ces deux transitions se produisent sous le verrouillage (lock) dpll dans les fonctions dpll_device_register() et dpll_device_unregister(). Une notification de pin pour un pin dont tous les DPLL ont disparu est désormais ignorée avec -ENODEV au lieu de provoquer un plantage, et tous les appelants du noyau ignorent cette valeur de retour.
WARNING: drivers/dpll/dpll_core.c:1092 à dpll_device_ops+0x24/0x40, CPU#83 : kworker/u576:3/23471 Modules liés en mémoire (linked in) : ... ice ... zl3073x_i2c(-) ... zl3073x ... File d'attente de travail (Workqueue) : ice_dpll_wq ice_dpll_pin_notify_work [ice]
RIP: 0010:dpll_device_ops+0x24/0x40 Pile d'appels (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> ---[ fin de la trace 0000000000000000 ]---
BUG: déréférencement d'un pointeur NULL dans le noyau, adresse : 0000000000000010 #PF : accès en lecture superviseur (supervisor) en mode noyau #PF : code d'erreur (0x0000) - page non présente
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.