Homepage

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

Threat Intelligence

EPSS
0.05% (15th 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-6757176
  • published2 May 2024
  • disclosed1 May 2024
Report a new vulnerability Found a mistake?

Introduced: 1 May 2024

CVE-2024-27002  (opens in a new tab)
CWE-667  (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:

clk: mediatek: Do a runtime PM get on controllers during probe

mt8183-mfgcfg has a mutual dependency with genpd during the probing stage, which leads to a deadlock in the following call stack:

CPU0: genpd_lock --> clk_prepare_lock genpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock()

CPU1: clk_prepare_lock --> genpd_lock clk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock()

Do a runtime PM get at the probe function to make sure clk_register() won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg, do this on all mediatek clock controller probings because we don't believe this would cause any regression.

Verified on MT8183 and MT8192 Chromebooks.