Improper Control of a Resource Through its Lifetime The advisory has been revoked - it doesn't affect any version of package rv  (opens in a new tab)


Threat Intelligence

EPSS
0.01% (2nd percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-CENTOS9-RV-13232002
  • published3 Oct 2025
  • disclosed1 Oct 2025

Introduced: 1 Oct 2025

CVE-2025-39905  (opens in a new tab)
CWE-664  (opens in a new tab)

Amendment

The Centos security team deemed this advisory irrelevant for Centos:9.

NVD Description

Note: Versions mentioned in the description apply only to the upstream rv package and not the rv package as distributed by Centos.

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.