Race Condition Affecting rv package, versions <0:6.12.0-124.27.1.el10_1


Severity

Recommended
0.0
high
0
10

Based on Oracle Linux security rating.

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 Learn

Learn about Race Condition vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-ORACLE10-RV-14921516
  • published13 Jan 2026
  • disclosed1 Oct 2025

Introduced: 1 Oct 2025

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

How to fix?

Upgrade Oracle:10 rv to version 0:6.12.0-124.27.1.el10_1 or higher.
This issue was patched in ELSA-2026-0453.

NVD Description

Note: Versions mentioned in the description apply only to the upstream rv package and not the rv package as distributed by Oracle. See How to fix? for Oracle:10 relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1