CVE-2024-50006 in Linux
Summary
by MITRE • 10/21/2024
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
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 03/22/2026
The vulnerability described in CVE-2024-50006 represents a critical deadlock condition within the Linux kernel's ext4 filesystem implementation that stems from improper lock ordering during asynchronous journaling operations. This issue manifests specifically when the ext4_ind_migrate() function attempts to migrate indirect blocks while maintaining synchronization guarantees through the EXT4_IOC_MIGRATE ioctl with O_SYNC flag. The root cause lies in the incorrect unlocking sequence of the i_data_sem lock within the migration code path, which creates a circular dependency scenario that can result in system-wide deadlock conditions. The vulnerability is particularly concerning because it demonstrates a failure in lock ordering validation that can be exploited through carefully crafted filesystem operations.
The technical flaw occurs within the jbd2 (journaling block device) subsystem where the jbd2_journal_stop() function attempts to acquire a jbd2_handle lock while holding the i_data_sem lock, creating a potential deadlock scenario that violates standard lock ordering principles. This issue is specifically triggered when CONFIG_PROVE_LOCKING is enabled, which activates the kernel's lock validation subsystem that detects and reports improper lock ordering patterns. The race condition emerges when an EXT4_IOC_MIGRATE ioctl call with synchronous requirements competes with concurrent write(2) system calls, causing the jbd2_might_wait_for_commit() macro to execute with conflicting lock acquisition orders. This creates a scenario where the same jbd2_handle can be locked twice in different orders, violating the fundamental lock ordering constraints that prevent deadlock conditions.
The operational impact of this vulnerability extends beyond simple system hangs, as it can lead to complete system lockups that require manual intervention or system reboot to resolve. When triggered, the deadlock condition prevents any further filesystem operations from proceeding, effectively rendering the affected filesystem inaccessible to userspace applications. The vulnerability affects systems running kernels with CONFIG_PROVE_LOCKING enabled, which is typically found in development and testing environments but may also be present in production systems where strict locking validation is enabled. The issue is particularly dangerous because it can be triggered through legitimate filesystem operations rather than requiring malicious input, making it a significant concern for system administrators managing critical infrastructure.
Mitigation strategies for this vulnerability should focus on immediate kernel updates that address the improper lock ordering in ext4_ind_migrate(), as well as careful monitoring of systems where CONFIG_PROVE_LOCKING is enabled. System administrators should prioritize applying the relevant kernel patches that correct the i_data_sem unlock order within the migration function. Additionally, organizations should consider temporarily disabling CONFIG_PROVE_LOCKING in production environments where this vulnerability could be exploited through legitimate system operations. The fix addresses the core issue by ensuring proper lock ordering between jbd2_handle and i_data_sem locks, preventing the circular dependency that leads to deadlock conditions. This vulnerability aligns with CWE-367, which specifically addresses Time-of-Check to Time-of-Use (TOCTOU) race conditions and improper lock ordering, and represents a classic example of how kernel lock management failures can lead to system-wide availability issues. The vulnerability also relates to ATT&CK technique T1490, which covers resource hijacking through system lock manipulation, as the deadlock condition effectively hijacks system resources and prevents normal operation.