CVE-2026-89494
UnknownSummary
In the Linux kernel, the ocfs2 dlm_mig_lockres_handler trusted the num_locks and lockname_len fields from a DLM_MIG_LOCKRES message without validation. This led to an out-of-bounds read (BUG_ON panic) and a heap out-of-bounds write when copying the lock name into a fixed 32-byte object. Any node in the domain could trigger this.
Risk Assessment
A malicious node in the cluster can cause a kernel panic (denial of service) or corrupt heap memory, potentially leading to kernel code execution. This affects the stability and security of the entire OCFS2 cluster.
Recommendation
Update the Linux kernel to a version containing the fix that validates lockname_len, num_locks, and payload size in dlm_mig_lockres_handler. If updating is not possible, consider limiting trust to nodes within the DLM domain.
Other vulnerabilities in Linux kernel (ocfs2)
See all- CVE-2026-89496Unknown
In the Linux kernel, the ocfs2 filesystem has a memory leak during copy-on-write operations triggered by copy_file_range() within the same filesystem. The issue was found by fuzzing and occurs because deallocations are not always run on copy-on-write completion, leading to unreferenced memory allocations.
- CVE-2026-89493Unknown
The Linux kernel ocfs2 module lacked validation of the rl_used and rl_count fields in the refcount block. A crafted or corrupted ocfs2 image with rl_used set to 0xffff causes an out-of-bounds read past the metadata block and a subsequent out-of-bounds memmove during a reflink (FICLONE) operation. Exploitation requires local access (CAP_SYS_ADMIN mounting a crafted image or raw write to the backing block device).
- CVE-2026-89492Unknown
A vulnerability was found in the Linux kernel's ocfs2 module due to missing validation of directory-index entry counts when reading metadata. The functions ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() do not bound the de_num_used and de_count fields against the block capacity, allowing a crafted on-disk image to set them to 0xffff and cause an out-of-bounds read past the 4KB metadata block. The flaw is reachable from any path lookup, stat() or open() on an indexed directory once the image is mounted.
- CVE-2026-89490Unknown
In the Linux kernel, the ocfs2 function ocfs2_dir_foreach_blk_el() on 32-bit kernels incorrectly computed the directory position mask, clearing the high 32 bits of the position. When readdir() crossed the 4 GiB boundary, the position was reset, causing infinite re-enumeration of already-returned directory entries.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: ocfs2: validate lengths in dlm_mig_lockres_handler A node receiving a DLM_MIG_LOCKRES message trusts several fields of the peer-supplied dlm_migratable_lockres without validation. num_locks and lockname_len are bounded only on the sending side, and the message is never checked to actually carry num_locks migratable_lock entries. As a result dlm_process_recovery_data() walks mres->ml[0..num_locks) past the kmalloc(data_len) copy of the message (an out-of-bounds read that ends in a BUG_ON panic), and dlm_init_lockres() copies lockname_len bytes into the fixed 32-byte o2dlm_lockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain. Validate these fields right after dlm_grab(), before anything uses them -- including the not-joined error path, which already prints mres->lockname with the unbounded lockname_len as a %.*s precision. Reject the message unless lockname_len <= DLM_LOCKID_NAME_MAX, num_locks <= DLM_MAX_MIGRATABLE_LOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.