Improper Locking Affecting kernel-livepatch-6_4_0-150600_10_20-rt package, versions <1-150600.1.3.1


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server 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-SLES156-KERNELLIVEPATCH6401506001020RT-8503254
  • published14 Dec 2024
  • disclosed13 Dec 2024

Introduced: 13 Dec 2024

NewCVE-2024-50006  (opens in a new tab)
CWE-667  (opens in a new tab)

How to fix?

Upgrade SLES:15.6 kernel-livepatch-6_4_0-150600_10_20-rt to version 1-150600.1.3.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-livepatch-6_4_0-150600_10_20-rt package and not the kernel-livepatch-6_4_0-150600_10_20-rt package as distributed by SLES. See How to fix? for SLES:15.6 relevant fixed versions and status.

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

ext4: fix i_data_sem unlock order in ext4_ind_migrate()

Fuzzing reports a possible deadlock in jbd2_log_wait_commit.

This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call.

This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously.

Found by Linux Verification Center (linuxtesting.org) with syzkaller.

Rule: add

CVSS Scores

version 3.1