Deadlock Affecting perf package, versions *


Severity

Recommended
low

Based on CentOS security rating.

Threat Intelligence

EPSS
0.1% (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-CENTOS6-PERF-17087036
  • published29 May 2026
  • disclosed28 May 2026

Introduced: 28 May 2026

NewCVE-2026-46165  (opens in a new tab)
CWE-833  (opens in a new tab)

How to fix?

There is no fixed version for Centos:6 perf.

NVD Description

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

In the Linux kernel, the following vulnerability has been resolved:

openvswitch: vport: fix self-deadlock on release of tunnel ports

vports are used concurrently and protected by RCU, so netdev_put() must happen after the RCU grace period. So, either in an RCU call or after the synchronize_net(). The rtnl_delete_link() must happen under RTNL and so can't be executed in RCU context. Calling synchronize_net() while holding RTNL is not a good idea for performance and system stability under load in general, so calling netdev_put() in RCU call is the right solution here.

However, when the device is deleted, rtnl_unlock() will call netdev_run_todo() and block until all the references are gone. In the current code this means that we never reach the call_rcu() and the vport is never freed and the reference is never released, causing a self-deadlock on device removal.

Fix that by moving the rcu_call() before the rtnl_unlock(), so the scheduled RCU callback will be executed when synchronize_net() is called from the rtnl_unlock()->netdev_run_todo() while the RTNL itself is already released.

CVSS Base Scores

version 3.1