CVE-2022-50277 in Linux
Summary
by MITRE • 09/15/2025
In the Linux kernel, the following vulnerability has been resolved:
ext4: don't allow journal inode to have encrypt flag
Mounting a filesystem whose journal inode has the encrypt flag causes a NULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt' mount option is used.
The problem is that when jbd2_journal_init_inode() calls bmap(), it eventually finds its way into ext4_iomap_begin(), which calls fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if the inode is encrypted, then its encryption key must already be set up. That's not the case here, since the journal inode is never "opened" like a normal file would be. Hence the crash.
A reproducer is:
mkfs.ext4 -F /dev/vdb debugfs -w /dev/vdb -R "set_inode_field <8> flags 0x80808" mount /dev/vdb /mnt -o inlinecrypt
To fix this, make ext4 consider journal inodes with the encrypt flag to be invalid. (Note, maybe other flags should be rejected on the journal inode too. For now, this is just the minimal fix for the above issue.)
I've marked this as fixing the commit that introduced the call to fscrypt_limit_io_blocks(), since that's what made an actual crash start being possible. But this fix could be applied to any version of ext4 that supports the encrypt feature.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/10/2026
The vulnerability described in CVE-2022-50277 represents a critical null pointer dereference issue within the Linux ext4 filesystem implementation that arises during specific mount operations involving encrypted journal inodes. This flaw occurs when a filesystem is mounted with the inlinecrypt option and contains a journal inode with the encryption flag set, creating a scenario where the kernel's filesystem encryption subsystem attempts to access encryption keys that have never been properly initialized for the journal inode. The issue stems from the improper handling of journal inode properties during the filesystem mounting process, specifically when the jbd2_journal_init_inode() function invokes bmap() which eventually leads to ext4_iomap_begin() calling fscrypt_limit_io_blocks(). The cryptographic subsystem requires that encryption keys be established before processing encrypted inodes, but journal inodes bypass normal file opening procedures and therefore lack initialized encryption contexts, resulting in a crash when the system attempts to dereference a null pointer.
The technical implementation of this vulnerability demonstrates a fundamental flaw in the filesystem's inode validation and encryption handling logic. When the ext4 filesystem attempts to initialize a journal inode, the call path traverses through multiple kernel subsystems including the journaling subsystem (jbd2) and the filesystem encryption layer. The function fscrypt_limit_io_blocks() is designed to enforce encryption policy constraints but fails to account for the special nature of journal inodes which are not subject to normal file operations and encryption key management procedures. This creates a scenario where the filesystem encryption subsystem makes assumptions about inode encryption state that are invalid for journal inodes, leading to the NULL dereference condition. The vulnerability is particularly concerning because it occurs at mount time, meaning any user with access to create or modify filesystem structures can potentially trigger this crash, making it exploitable for denial of service attacks.
The operational impact of this vulnerability extends beyond simple system crashes to potentially compromise system availability and stability. When exploited, the vulnerability can cause immediate system crashes or hangs during filesystem mounting operations, effectively preventing legitimate access to the affected storage devices. This behavior aligns with the Common Weakness Enumeration (CWE) classification for CWE-476 NULL Pointer Dereference, which represents a well-known security weakness where software attempts to access a memory location pointed to by a null reference. From an ATT&CK framework perspective, this vulnerability maps to T1499.004 for Network Denial of Service and potentially T1566.001 for Phishing with Social Engineering, as it can be used to disrupt system availability through carefully crafted filesystem modifications. The vulnerability affects all versions of ext4 that support the encryption feature and have the specific call path that introduced fscrypt_limit_io_blocks(), making it a widespread concern across various Linux kernel versions.
The recommended mitigation strategy involves implementing a validation check that explicitly rejects journal inodes with encryption flags set during the filesystem initialization process. This approach aligns with the principle of least privilege and defensive programming practices by ensuring that the filesystem encryption subsystem does not attempt to process journal inodes through normal encryption pathways. The fix should be applied at the ext4 filesystem layer where journal inodes are validated, specifically modifying the journal inode handling code to recognize and reject encryption flags on journal inodes. System administrators should ensure that all affected systems are updated with patches that implement this validation, and organizations should conduct thorough testing to verify that the fix does not introduce regressions in normal filesystem operations. Additionally, monitoring systems should be configured to detect attempts to modify filesystem structures in ways that could trigger this vulnerability, as such modifications may indicate potential malicious activity targeting system availability.