Deadlock Affecting kernel-kdump-devel package, versions *


Severity

Recommended
0.0
medium
0
10

Based on Red Hat Enterprise Linux security rating.

Threat Intelligence

EPSS
0.04% (6th 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-KERNELKDUMPDEVEL-6644301
  • published18 Apr 2024
  • disclosed17 Apr 2024

Introduced: 17 Apr 2024

CVE-2024-26899  (opens in a new tab)
CWE-833  (opens in a new tab)

How to fix?

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

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-kdump-devel package and not the kernel-kdump-devel 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:

block: fix deadlock between bd_link_disk_holder and partition scan

'open_mutex' of gendisk is used to protect open/close block devices. But in bd_link_disk_holder(), it is used to protect the creation of symlink between holding disk and slave bdev, which introduces some issues.

When bd_link_disk_holder() is called, the driver is usually in the process of initialization/modification and may suspend submitting io. At this time, any io hold 'open_mutex', such as scanning partitions, can cause deadlocks. For example, in raid:

T1 T2 bdev_open_by_dev lock open_mutex [1] ... efi_partition ... md_submit_bio md_ioctl mddev_syspend -> suspend all io md_add_new_disk bind_rdev_to_array bd_link_disk_holder try lock open_mutex [2] md_handle_request -> wait mddev_resume

T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume mddev, but T2 waits for open_mutex held by T1. Deadlock occurs.

Fix it by introducing a local mutex 'blk_holder_mutex' to replace 'open_mutex'.

CVSS Scores

version 3.1