CVE-2022-50436 in Linux
Summary
by MITRE • 10/01/2025
In the Linux kernel, the following vulnerability has been resolved:
ext4: don't set up encryption key during jbd2 transaction
Commit a80f7fcf1867 ("ext4: fixup ext4_fc_track_* functions' signature") extended the scope of the transaction in ext4_unlink() too far, making it include the call to ext4_find_entry(). However, ext4_find_entry() can deadlock when called from within a transaction because it may need to set up the directory's encryption key.
Fix this by restoring the transaction to its original scope.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 03/20/2026
The vulnerability identified as CVE-2022-50436 represents a critical issue within the Linux kernel's ext4 filesystem implementation that stems from improper transaction management during directory operations. This flaw specifically affects the interaction between the journaling subsystem jbd2 and the ext4 filesystem's encryption capabilities, creating a scenario where system stability and security can be compromised. The vulnerability manifests when the ext4_unlink() function attempts to remove directory entries while maintaining an active journal transaction, leading to potential deadlock conditions that can bring system operations to a halt.
The technical root cause of this vulnerability lies in the improper scoping of journal transactions within the ext4 filesystem codebase. The problematic commit a80f7fcf1867 inadvertently expanded the transaction scope beyond its intended boundaries, causing the ext4_unlink() function to encompass the ext4_find_entry() call within the same transaction context. This expansion creates a circular dependency where the function attempting to find directory entries must set up encryption keys, but this operation cannot proceed while the transaction is active. The jbd2 subsystem's transaction management conflicts with the encryption key setup process, resulting in a deadlock condition that prevents further filesystem operations from completing successfully.
This vulnerability directly impacts system reliability and can be classified under CWE-367, which addresses the Time-of-Check to Time-of-Use (TOCTOU) race condition, and CWE-121, which covers stack-based buffer overflow conditions. From an operational perspective, the vulnerability creates a denial of service condition where filesystem operations become unresponsive, potentially affecting critical system services and user applications that depend on file access. The issue particularly affects systems running ext4 filesystems with encryption enabled, as the deadlock occurs specifically when encryption key setup is required during directory traversal operations.
The operational impact extends beyond simple system unresponsiveness to include potential data integrity concerns and extended system downtime. When the deadlock condition occurs, the affected processes become stuck indefinitely, consuming system resources while failing to complete their intended operations. This can lead to cascading failures where dependent services also become unresponsive, ultimately affecting system availability and user productivity. The vulnerability is particularly concerning in enterprise environments where continuous system availability is critical for business operations and where encryption is commonly implemented for data protection.
Mitigation strategies for CVE-2022-50436 involve applying the kernel patch that restores the original transaction scope, effectively separating the ext4_find_entry() call from the jbd2 transaction context. System administrators should prioritize updating to kernel versions that include the fix, typically kernel versions 5.18.13 or later, where the transaction boundaries have been properly restored. Organizations should also consider implementing monitoring solutions to detect potential deadlock conditions and establish recovery procedures for systems that may be affected by this vulnerability. The fix aligns with ATT&CK technique T1499.004, which covers system shutdown/reboot, as the vulnerability can lead to system unresponsiveness that may require manual intervention to resolve. Regular kernel updates and security patch management procedures should be enforced to prevent similar issues from arising in the future, particularly when modifying transaction management boundaries in critical subsystems.