CVE-2022-49337 in Linux
Summary
by MITRE • 02/26/2025
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
When user_dlm_destroy_lock failed, it didn't clean up the flags it set before exit. For USER_LOCK_IN_TEARDOWN, if this function fails because of lock is still in used, next time when unlink invokes this function, it will return succeed, and then unlink will remove inode and dentry if lock is not in used(file closed), but the dlm lock is still linked in dlm lock resource, then when bast come in, it will trigger a panic due to user-after-free. See the following panic call trace. To fix this, USER_LOCK_IN_TEARDOWN should be reverted if fail. And also error should be returned if USER_LOCK_IN_TEARDOWN is set to let user know that unlink fail.
For the case of ocfs2_dlm_unlock failure, besides USER_LOCK_IN_TEARDOWN, USER_LOCK_BUSY is also required to be cleared. Even though spin lock is released in between, but USER_LOCK_IN_TEARDOWN is still set, for USER_LOCK_BUSY, if before every place that waits on this flag, USER_LOCK_IN_TEARDOWN is checked to bail out, that will make sure no flow waits on the busy flag set by user_dlm_destroy_lock(), then we can simplely revert USER_LOCK_BUSY when ocfs2_dlm_unlock fails. Fix user_dlm_cluster_lock() which is the only function not following this.
[ 941.336392] (python,26174,16):dlmfs_unlink:562 ERROR: unlink
004fb0000060000b5a90b8c847b72e1, error -16 from destroy [ 989.757536] ------------[ cut here ]------------
[ 989.757709] kernel BUG at fs/ocfs2/dlmfs/userdlm.c:173!
[ 989.757876] invalid opcode: 0000 [#1] SMP
[ 989.758027] Modules linked in: ksplice_2zhuk2jr_ib_ipoib_new(O)
ksplice_2zhuk2jr(O) mptctl mptbase xen_netback xen_blkback xen_gntalloc xen_gntdev xen_evtchn cdc_ether usbnet mii ocfs2 jbd2 rpcsec_gss_krb5 auth_rpcgss nfsv4 nfsv3 nfs_acl nfs fscache lockd grace ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue configfs bnx2fc fcoe libfcoe libfc scsi_transport_fc sunrpc ipmi_devintf bridge stp llc rds_rdma rds bonding ib_sdp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm falcon_lsm_serviceable(PE) falcon_nf_netcontain(PE) mlx4_vnic falcon_kal(E) falcon_lsm_pinned_13402(E) mlx4_ib ib_sa ib_mad ib_core ib_addr xenfs xen_privcmd dm_multipath iTCO_wdt iTCO_vendor_support pcspkr sb_edac edac_core i2c_i801 lpc_ich mfd_core ipmi_ssif i2c_core ipmi_si ipmi_msghandler [ 989.760686] ioatdma sg ext3 jbd mbcache sd_mod ahci libahci ixgbe dca ptp
pps_core vxlan udp_tunnel ip6_udp_tunnel megaraid_sas mlx4_core crc32c_intel be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 mdio libiscsi_tcp qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded:
ksplice_2zhuk2jr_ib_ipoib_old] [ 989.761987] CPU: 10 PID: 19102 Comm: dlm_thread Tainted: P OE
4.1.12-124.57.1.el6uek.x86_64 #2 [ 989.762290] Hardware name: Oracle Corporation ORACLE SERVER
X5-2/ASM,MOTHERBOARD,1U, BIOS 30350100 06/17/2021 [ 989.762599] task: ffff880178af6200 ti: ffff88017f7c8000 task.ti:
ffff88017f7c8000 [ 989.762848] RIP: e030:[] []
__user_dlm_queue_lockres.part.4+0x76/0x80 [ocfs2_dlmfs]
[ 989.763185] RSP: e02b:ffff88017f7cbcb8 EFLAGS: 00010246
[ 989.763353] RAX: 0000000000000000 RBX: ffff880174d48008 RCX:
0000000000000003 [ 989.763565] RDX: 0000000000120012 RSI: 0000000000000003 RDI:
ffff880174d48170 [ 989.763778] RBP: ffff88017f7cbcc8 R08: ffff88021f4293b0 R09:
0000000000000000 [ 989.763991] R10: ffff880179c8c000 R11: 0000000000000003 R12:
ffff880174d48008 [ 989.764204] R13: 0000000000000003 R14: ffff880179c8c000 R15:
ffff88021db7a000 [ 989.764422] FS: 0000000000000000(0000) GS:ffff880247480000(0000)
knlGS:ffff880247480000 [ 989.764685] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 989.764865] CR2: ffff8000007f6800 CR3: 0000000001ae0000 CR4:
0000000000042660 [ 989.765081] Stack:
[ 989.765167] 00000000000
---truncated---
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/16/2026
The vulnerability described in CVE-2022-49337 affects the Linux kernel's ocfs2 distributed lock manager filesystem implementation, specifically within the dlmfs subsystem. This issue stems from improper error handling in the user_dlm_destroy_lock function, which manages the cleanup of distributed locks during file unlink operations. The flaw manifests when the function fails to properly reset internal flags before exiting, leading to a cascade of errors that can result in system panics.
The core technical problem occurs when USER_LOCK_IN_TEARDOWN flag is set but the function fails during lock destruction. This failure prevents the proper cleanup of lock state, creating a scenario where subsequent unlink operations may incorrectly assume the lock is no longer in use. The vulnerability is particularly dangerous because it can lead to use-after-free conditions when bast (bestowal) callbacks attempt to access memory that has already been freed. The panic trace shows the kernel crashing at fs/ocfs2/dlmfs/userdlm.c:173, indicating a direct memory access violation when the system attempts to process a stale lock reference.
According to CWE classification, this vulnerability maps to CWE-459: Incomplete Cleanup, which describes incomplete or incorrect cleanup of resources, and CWE-476: NULL Pointer Dereference, which occurs when a null pointer is dereferenced. The issue also aligns with ATT&CK technique T1490: Inhibit System Recovery, as the improper cleanup can lead to system instability and potential denial of service conditions. The error handling failure in ocfs2_dlm_unlock function compounds the problem by failing to clear the USER_LOCK_BUSY flag, which creates a race condition where different code paths may wait indefinitely on flags that were never properly reset.
The operational impact of this vulnerability is significant for systems using Oracle Cluster File System 2 (OCFS2) with distributed locking capabilities. When exploited, it can cause system crashes, data corruption, or complete system hangs during file operations involving distributed locks. The vulnerability affects systems where OCFS2 is deployed with dlmfs, particularly in high-availability configurations where distributed locking is critical for maintaining data consistency across multiple nodes.
Mitigation strategies should focus on applying the kernel patch that properly resets the USER_LOCK_IN_TEARDOWN and USER_LOCK_BUSY flags when user_dlm_destroy_lock fails. Administrators should ensure all systems running affected kernel versions receive updates promptly. Additionally, monitoring systems should be configured to detect unusual patterns in dlmfs operations and alert on potential lock state inconsistencies. The fix requires careful attention to ensure that all code paths properly handle the flag reset operations, particularly in functions like user_dlm_cluster_lock that were not following the established error handling pattern. System administrators should also consider implementing process isolation and resource monitoring to detect and contain potential lock-related failures before they can cause system-wide issues.