CVE-2024-27002 Affecting kernel-kdump package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.05% (18th 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-RHEL6-KERNELKDUMP-6790763
  • published26 Nov 2024
  • disclosed1 May 2024

Introduced: 1 May 2024

CVE-2024-27002  (opens in a new tab)

How to fix?

There is no fixed version for RHEL:6 kernel-kdump.

NVD Description

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

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.

CVSS Scores

version 3.1