CVE-2022-49337 is a vulnerability in the Linux kernel specifically affecting the OCFS2 (Oracle Cluster File System version 2) distributed lock manager filesystem (dlmfs) component. The flaw arises from improper error handling in the user_dlm_destroy_lock function. When this function fails to destroy a lock because the lock is still in use, it does not properly clean up the flags it sets, particularly USER_LOCK_IN_TEARDOWN. This improper cleanup causes subsequent unlink operations to incorrectly succeed, leading to the removal of inode and dentry structures even though the distributed lock (dlm lock) remains linked to the lock resource. This inconsistency results in a use-after-free condition when the lock resource is accessed later, triggering a kernel panic and system crash. The vulnerability also involves improper handling of the USER_LOCK_BUSY flag during ocfs2_dlm_unlock failure, which can cause waiting flows to stall or behave incorrectly. The root cause is that the flags USER_LOCK_IN_TEARDOWN and USER_LOCK_BUSY are not reverted or cleared properly on failure paths, leading to inconsistent lock states and kernel instability. The vulnerability can cause denial of service (DoS) through kernel panic and system crash. The provided kernel panic trace shows the failure occurring in the userdlm.c source file, confirming the critical nature of the flaw in the OCFS2 distributed lock manager. The vulnerability affects Linux kernel versions containing the flawed OCFS2 dlmfs implementation prior to the patch. No known exploits are reported in the wild yet, and no CVSS score has been assigned. The vulnerability requires local interaction with the OCFS2 filesystem and the distributed lock manager interface, implying that exploitation requires access to systems using OCFS2 with distributed locking enabled. This flaw is particularly relevant for clustered Linux environments using OCFS2 for shared storage, such as Oracle RAC clusters or other high-availability setups relying on OCFS2. The vulnerability was published on 26 February 2025 and is marked as resolved in newer kernel versions by fixing the error handling to revert flags and return appropriate errors to the user space.

For European organizations, the impact of CVE-2022-49337 can be significant in environments that utilize OCFS2 for clustered file systems, particularly in sectors relying on high-availability and shared storage solutions such as financial services, telecommunications, cloud service providers, and large enterprises running Oracle RAC or similar clustered database systems. The vulnerability can lead to kernel panics and denial of service, causing unplanned downtime, data unavailability, and potential disruption of critical business operations. Since OCFS2 is used in clustered environments, the failure of one node due to this vulnerability can impact the entire cluster's stability and availability. This could result in cascading failures or degraded performance in distributed applications. Additionally, the use-after-free condition could theoretically be leveraged for privilege escalation or arbitrary code execution by a skilled attacker with local access, although no such exploits are currently known. The requirement for local access limits remote exploitation but insider threats or compromised accounts could trigger the vulnerability. The impact on confidentiality is low, but integrity and availability are at risk due to potential data corruption or loss caused by improper unlink operations and system crashes. Organizations in Europe with critical infrastructure or regulated industries must prioritize patching to maintain compliance and operational continuity.

1. Apply the official Linux kernel patches that address CVE-2022-49337 as soon as they become available from trusted sources or Linux distribution vendors. 2. For organizations using OCFS2 in clustered environments, schedule maintenance windows to update kernel versions to patched releases to avoid disruption. 3. Monitor kernel logs and system messages for signs of dlmfs unlink errors or kernel panics related to OCFS2 to detect attempts to trigger the vulnerability. 4. Restrict local access to systems running OCFS2 to trusted administrators and users only, minimizing the risk of exploitation by unauthorized personnel. 5. Implement strict access controls and auditing on clustered file systems to detect anomalous unlink or lock operations. 6. Consider alternative cluster file systems or distributed lock managers if patching is delayed and risk is unacceptable. 7. Engage with Linux distribution security advisories and subscribe to vulnerability notifications to stay informed about updates and mitigations. 8. Test patches in staging environments replicating production cluster configurations to ensure stability before deployment. 9. Harden kernel parameters and enable security modules (e.g., SELinux, AppArmor) to reduce the attack surface and contain potential exploitation attempts. 10. Document and rehearse incident response procedures for kernel panic or cluster node failures to minimize downtime and data loss.