CVE-2026-72161 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: add journal NULL check in ocfs2_checkpoint_inode()
During unmount, ocfs2_journal_shutdown() frees the journal and sets osb->journal to NULL. Later, when VFS evicts remaining cached inodes, ocfs2_evict_inode() -> ocfs2_clear_inode() -> ocfs2_checkpoint_inode() -> ocfs2_ci_fully_checkpointed() dereferences osb->journal, causing a NULL pointer dereference.
Fix this by adding a NULL check for osb->journal in ocfs2_checkpoint_inode(). If the journal is NULL, it has already been fully flushed and destroyed during shutdown, so there is nothing to checkpoint.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability described represents a critical null pointer dereference condition within the Oracle Cluster File System 2 ocfs2 kernel module that can lead to system crashes during filesystem unmount operations. This issue occurs in the Linux kernel's handling of cluster file systems where proper resource cleanup sequences are not maintained, creating a scenario where subsequent operations attempt to access already freed memory structures.
The technical flaw manifests specifically within the ocfs2_checkpoint_inode() function which lacks proper null pointer validation before accessing the osb->journal member variable. During normal filesystem shutdown procedures, ocfs2_journal_shutdown() executes and frees the journal structure while simultaneously setting the osb->journal pointer to NULL to indicate the journal's destruction. However, the subsequent eviction process initiated by the Virtual File System layer continues to invoke cleanup operations on cached inodes without proper state validation.
When the VFS subsystem processes remaining cached inodes during unmount operations, it triggers a cascade of function calls including ocfs2_evict_inode() -> ocfs2_clear_inode() -> ocfs2_checkpoint_inode() -> ocfs2_ci_fully_checkpointed(), where each step in this chain attempts to dereference the osb->journal pointer without first verifying its validity. This sequence creates a direct path to kernel memory corruption and system instability when the journal has already been destroyed but cleanup operations continue to reference it.
The operational impact of this vulnerability extends beyond simple system crashes, potentially exposing systems to denial of service conditions that can affect cluster availability in enterprise environments where ocfs2 filesystems are deployed. The flaw particularly affects systems running Oracle Cluster File System 2 implementations where multiple nodes access shared storage, as the unmount process failure could propagate across the cluster and compromise overall system stability. This vulnerability directly relates to CWE-476 which describes null pointer dereference conditions in software systems.
From an attack perspective, this vulnerability aligns with ATT&CK technique T1490 which involves creating or deploying malicious code that targets system stability through memory corruption vulnerabilities. While the flaw itself may not be directly exploitable for privilege escalation, it can serve as a vector for denial of service attacks against cluster file systems, particularly in environments where filesystem unmount operations are frequent or automated.
The fix implemented addresses this issue by introducing a simple but critical null pointer check within the ocfs2_checkpoint_inode() function before any journal operations are attempted. This approach follows established security practices for preventing null pointer dereference vulnerabilities and aligns with defensive programming principles recommended in industry standards. When the journal is detected as NULL, the function properly returns without attempting checkpoint operations since the journal has already been fully flushed and destroyed during the shutdown sequence, making any further checkpointing unnecessary and potentially harmful.
The mitigation strategy reinforces proper resource management protocols within kernel space where cleanup sequences must maintain proper state tracking to prevent subsequent access to freed resources. This implementation demonstrates the importance of maintaining consistent state validation throughout complex multi-step operations, particularly in cluster file system implementations where multiple subsystems interact during shutdown procedures. The fix ensures that kernel modules properly handle the transition states between active operation and resource cleanup, preventing the cascade of invalid memory accesses that could lead to system crashes or more severe stability issues.