CVE-2025-39905

In the Linux kernel, the following vulnerability has been resolved: net: phylink: add lock for serializing concurrent pl->phydev writes with resolver Currently phylink_resolve() protects itself against concurrent phylink_bringup_phy() or phylink_disconnect_phy() calls which modify pl->phydev by relying on pl->state_mutex. The problem is that in phylink_resolve(), pl->state_mutex is in a lock inversion state with pl->phydev->lock. So pl->phydev->lock needs to be acquired prior to pl->state_mutex. But that requires dereferencing pl->phydev in the first place, and without pl->state_mutex, that is racy. Hence the reason for the extra lock. Currently it is redundant, but it will serve a functional purpose once mutex_lock(&phy->lock) will be moved outside of the mutex_lock(&pl->state_mutex) section. Another alternative considered would have been to let phylink_resolve() acquire the rtnl_mutex, which is also held when phylink_bringup_phy() and phylink_disconnect_phy() are called. But since phylink_disconnect_phy() runs under rtnl_lock(), it would deadlock with phylink_resolve() when calling flush_work(&pl->resolve). Additionally, it would have been undesirable because it would have unnecessarily blocked many other call paths as well in the entire kernel, so the smaller-scoped lock was preferred.
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.17:rc5:*:*:*:*:*:*

History

19 Oct 2026, 21:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net: phylink: añadir un bloqueo para serializar escrituras concurrentes de pl->phydev con el resolvedor Actualmente, phylink_resolve() se protege contra llamadas concurrentes a phylink_bringup_phy() o phylink_disconnect_phy() que modifican pl->phydev al depender de pl->state_mutex. El problema es que en phylink_resolve(), pl->state_mutex está en un estado de inversión de bloqueo con pl->phydev->lock. Así que pl->phydev->lock necesita ser adquirido antes de pl->state_mutex. Pero eso requiere desreferenciar pl->phydev en primer lugar, y sin pl->state_mutex, eso es propenso a condiciones de carrera. De ahí la razón del bloqueo adicional. Actualmente es redundante, pero servirá un propósito funcional una vez que mutex_lock(&phy->lock) sea movido fuera de la sección mutex_lock(&pl->state_mutex). Otra alternativa considerada habría sido permitir que phylink_resolve() adquiera el rtnl_mutex, el cual también se mantiene cuando se llaman a phylink_bringup_phy() y phylink_disconnect_phy(). Pero dado que phylink_disconnect_phy() se ejecuta bajo rtnl_lock(), entraría en interbloqueo con phylink_resolve() al llamar a flush_work(&pl->resolve). Además, habría sido indeseable porque habría bloqueado innecesariamente muchas otras rutas de llamada también en todo el kernel, por lo que se prefirió el bloqueo de alcance más pequeño.

Information

Published : 2025-10-01 08:15

Updated : 2026-10-19 21:10


NVD link : CVE-2025-39905

Mitre link : CVE-2025-39905

CVE.ORG link : CVE-2025-39905


JSON object : View

Products Affected

linux

  • linux_kernel
CWE
CWE-362

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')