Improper Locking Affecting kernel-livepatch-5_14_21-150500_55_88-default package, versions <1-150500.11.5.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-SLES155-KERNELLIVEPATCH514211505005588DEFAULT-8525535
  • published18 Dec 2024
  • disclosed17 Dec 2024

Introduced: 17 Dec 2024

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

How to fix?

Upgrade SLES:15.5 kernel-livepatch-5_14_21-150500_55_88-default to version 1-150500.11.5.1 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-livepatch-5_14_21-150500_55_88-default package and not the kernel-livepatch-5_14_21-150500_55_88-default package as distributed by SLES. See How to fix? for SLES:15.5 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