CVE-2022-49337
published 2025-02-26CVE-2022-49337: 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…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.21%
11.2th percentile
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_d
Affected
23 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 5.18.5-1 (bookworm) | linux 5.18.5-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 2cd9888590c52ac7592e3607d0a3174ccd57ef86 < 1434cd71ad9f3a6beda3036972983b6c4869207c | 1434cd71ad9f3a6beda3036972983b6c4869207c |
| linux | linux | >= 2cd9888590c52ac7592e3607d0a3174ccd57ef86 < 02480e2e82ae0e5588374bbbcf4fa6e4959fa174 | 02480e2e82ae0e5588374bbbcf4fa6e4959fa174 |
| linux | linux | >= 2cd9888590c52ac7592e3607d0a3174ccd57ef86 < 733a35c00ef363a1c774d7ea486e0735b7c13a15 | 733a35c00ef363a1c774d7ea486e0735b7c13a15 |
| linux | linux | >= 2cd9888590c52ac7592e3607d0a3174ccd57ef86 < 82bf8e7271fade40184177cb406203addc34c4a0 | 82bf8e7271fade40184177cb406203addc34c4a0 |
| linux | linux | >= 2cd9888590c52ac7592e3607d0a3174ccd57ef86 < 337e36550788dbe03254f0593a231c1c4873b20d | 337e36550788dbe03254f0593a231c1c4873b20d |
| linux | linux | >= 2cd9888590c52ac7592e3607d0a3174ccd57ef86 < 9c96238fac045b289993d7bc5aae7b2d72b25c76 | 9c96238fac045b289993d7bc5aae7b2d72b25c76 |
| linux | linux | >= 2cd9888590c52ac7592e3607d0a3174ccd57ef86 < efb54ec548829e1d3605f0434526f86e345b1b28 | efb54ec548829e1d3605f0434526f86e345b1b28 |
| linux | linux | >= 2cd9888590c52ac7592e3607d0a3174ccd57ef86 < 2c5e26a626fe46675bceba853e12aaf13c712e10 | 2c5e26a626fe46675bceba853e12aaf13c712e10 |
| linux | linux | >= 2cd9888590c52ac7592e3607d0a3174ccd57ef86 < 863e0d81b6683c4cbc588ad831f560c90e494bef | 863e0d81b6683c4cbc588ad831f560c90e494bef |
| linux | linux_kernel | < 4.9.318 | 4.9.318 |
| linux | linux_kernel | >= 0 < 5.10.127-1 | 5.10.127-1 |
| linux | linux_kernel | >= 0 < 5.18.5-1 | 5.18.5-1 |
| linux | linux_kernel | >= 0 < 5.18.5-1 | 5.18.5-1 |
| linux | linux_kernel | >= 0 < 5.18.5-1 | 5.18.5-1 |
| linux | linux_kernel | >= 4.10 < 4.14.283 | 4.14.283 |
| linux | linux_kernel | >= 4.15 < 4.19.247 | 4.19.247 |
| linux | linux_kernel | >= 4.20 < 5.4.198 | 5.4.198 |
| linux | linux_kernel | >= 5.11 < 5.15.46 | 5.15.46 |
| linux | linux_kernel | >= 5.16 < 5.17.14 | 5.17.14 |
| linux | linux_kernel | >= 5.18 < 5.18.3 | 5.18.3 |
| linux | linux_kernel | >= 5.5 < 5.10.121 | 5.10.121 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
GHSA-xw4w-p39h-frx8: In the Linux kernel, the following vulnerability has been resolved:
ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
When user_dlm_destroy_
ghsa_unreviewed·2025-09-22
CVE-2022-49337 [MEDIUM] CWE-667 GHSA-xw4w-p39h-frx8: In the Linux kernel, the following vulnerability has been resolved:
ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
When user_dlm_destroy_
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
OSV
CVE-2022-49337: In the Linux kernel, the following vulnerability has been resolved: ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock When user_dlm_destroy_lo
osv·2025-02-26·CVSS 5.5
CVE-2022-49337 [MEDIUM] CVE-2022-49337: In the Linux kernel, the following vulnerability has been resolved: ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock When user_dlm_destroy_lo
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_un
Red Hat
kernel: ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
vendor_redhat·2025-02-26·CVSS 5.5
CVE-2022-49337 [MEDIUM] kernel: ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
kernel: ocfs2: dlmfs: fix error handling of user_dlm_destroy_lock
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
Debian
CVE-2022-49337: linux - In the Linux kernel, the following vulnerability has been resolved: ocfs2: dlmf...
vendor_debian·2022·CVSS 5.5
CVE-2022-49337 [MEDIUM] CVE-2022-49337: linux - In the Linux kernel, the following vulnerability has been resolved: ocfs2: dlmf...
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_un
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/02480e2e82ae0e5588374bbbcf4fa6e4959fa174https://git.kernel.org/stable/c/1434cd71ad9f3a6beda3036972983b6c4869207chttps://git.kernel.org/stable/c/2c5e26a626fe46675bceba853e12aaf13c712e10https://git.kernel.org/stable/c/337e36550788dbe03254f0593a231c1c4873b20dhttps://git.kernel.org/stable/c/733a35c00ef363a1c774d7ea486e0735b7c13a15https://git.kernel.org/stable/c/82bf8e7271fade40184177cb406203addc34c4a0https://git.kernel.org/stable/c/863e0d81b6683c4cbc588ad831f560c90e494befhttps://git.kernel.org/stable/c/9c96238fac045b289993d7bc5aae7b2d72b25c76https://git.kernel.org/stable/c/efb54ec548829e1d3605f0434526f86e345b1b28
2025-02-26
Published