CVE-2026-89494: ocfs2: validate lengths in dlm_mig_lockres_handler
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: validate lengths in dlmmiglockreshandler
A node receiving a DLMMIGLOCKRES message trusts several fields of the peer-supplied dlmmigratablelockres without validation. numlocks and locknamelen are bounded only on the sending side, and the message is never checked to actually carry numlocks migratablelock entries. As a result dlmprocessrecoverydata() walks mres->ml[0..numlocks) past the kmalloc(datalen) copy of the message (an out-of-bounds read that ends in a BUGON panic), and dlminitlockres() copies locknamelen bytes into the fixed 32-byte o2dlmlockname slab object (a heap out-of-bounds write). Both are reachable by any node in the domain.
Validate these fields right after dlmgrab(), before anything uses them -- including the not-joined error path, which already prints mres->lockname with the unbounded locknamelen as a %.s precision. Reject the message unless locknamelen <= DLMLOCKIDNAMEMAX, numlocks <= DLMMAXMIGRATABLELOCKS (the bound the sender already asserts), and the payload is large enough to hold the claimed locks. Conforming recovery and migration messages are unaffected.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In dlm_mig_lockres_handler, validate the peer-supplied fields (including lockname_len and num_locks) immediately after dlm_grab(), before anything uses them; reject the message on invalid values. Ensure lockname_len is bounded (e.g., lockname_len <= DLM_LOCKID_NAME_MAX) to prevent o2dlm_lockname slab out-of-bounds writes and bound the %.*s precision.
Linux kernel ocfs2 (dlm_mig_lockres_handler) mres->lockname_len / lockname_len validation = Reject message if lockname_len is unbounded/invalid (e.g., ensure lockname_len <= DLM_LOCKID_NAME_MAX) before any use - Configuration
In dlm_mig_lockres_handler, validate that num_locks is bounded by DLM_MAX_MIGRATABLE_LOCKS (the sender-asserted bound) and that the message payload is large enough to hold the claimed locks before dlm_init_lockres() copies lockname_len bytes and before dlm_process_recovery_data() walks mres->ml[0..num_locks). Reject if these checks fail (including the not-joined error path).
Linux kernel ocfs2 (dlm_mig_lockres_handler) num_locks bounds and payload size check = Reject message unless num_locks <= DLM_MAX_MIGRATABLE_LOCKS and payload is large enough for num_locks migratable_lock entries
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems participating in an OCFS2 DLM domain are exposed, because any node in that domain can send the affected DLM_MIG_LOCKRES message. Nodes that do not receive these recovery or migration messages are not identified as affected by the provided information.
What does an attacker need to exploit it?
An attacker needs the ability to act as a node in the OCFS2 DLM domain and send a crafted DLM_MIG_LOCKRES message. The crafted message can claim excessive lock counts or lock-name lengths, or omit lock entries that its count claims are present.
What is the potential impact of a malformed message?
Malformed fields can cause an out-of-bounds read that ends in a BUG_ON panic, creating a denial-of-service condition. An oversized lockname_len can also cause a heap out-of-bounds write into a fixed 32-byte lock-name object.
How can the issue be mitigated if an update cannot be applied immediately?
Limit participation in the OCFS2 DLM domain to trusted nodes, since any domain node can reach the vulnerable handler. Prevent untrusted systems from joining or sending DLM recovery and migration traffic within the domain.
How does the fix determine whether a message is safe?
The fix rejects messages when lockname_len exceeds DLM_LOCKID_NAME_MAX, num_locks exceeds DLM_MAX_MIGRATABLE_LOCKS, or the payload is too short to contain the claimed migratable lock entries. These checks occur before the supplied fields are used, including in error handling.