Improper Locking Affecting kernel-uek-modules package, versions <0:5.15.0-303.171.5.2.el9uek


Severity

Recommended
high

Based on Oracle 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-ORACLE9-KERNELUEKMODULES-8529598
  • published19 Dec 2024
  • disclosed21 Oct 2024

Introduced: 21 Oct 2024

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

How to fix?

Upgrade Oracle:9 kernel-uek-modules to version 0:5.15.0-303.171.5.2.el9uek or higher.
This issue was patched in ELSA-2024-12887.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-uek-modules package and not the kernel-uek-modules package as distributed by Oracle. See How to fix? for Oracle:9 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