Re: [vs] DLM debugfs information disclosure via non-null-terminated resource name

Dear maintainers,
There is an possible information disclosure vulnerability in the DLM
subsystem's debugfs interface. The issue resides in the function
print_format2_lock() in fs/dlm/debug_fs.c. When a resource name
is exactly DLM_RESNAME_MAXLEN bytes long and contains no null
byte, the %s format specifier in a seq_printf call reads beyond
the intended buffer, exposing adjacent kernel memory.
Description:
When printing lock information in format 2, the code does:
seq_printf(s, "... "%s"\n", r->res_name);
The res_name field is a fixed-size byte array of length
r->res_length (bounded by DLM_RESNAME_MAXLEN) and is not
guaranteed to be null-terminated. If an attacker creates a resource
with a name of maximum length consisting entirely of non-null bytes
(e.g., 64 'A's), the %s formatter will continue reading past the
end of the res_name buffer until it encounters a null byte in
kernel memory. This leaks the contents of the following memory,
which may include kernel pointers, slab metadata, or other sensitive
data.
Impact:
Local attacker on a system where
DLM is used (e.g., clustered servers running GFS2/OCFS2 with
dlm_controld) can read kernel memory beyond the resource name.
This defeats KASLR, reveals heap layout, and may expose credentials
or other secrets. The leak is a classic information disclosure that
can be used as a building block for further privilege escalation.
Initially;
Create a DLM lockspace (e.g., via dlm_tool join test_ls).
Acquire a lock on a resource with a 64-byte name of non-null
bytes (e.g., 64 'A's) using dlm_ls_lock_wait.
Read /sys/kernel/debug/dlm/test_ls/locks (format 2).
Observe the 64 'A's followed by disclosed kernel memory.
Proposed fix:
Perhaps replacing the unbounded %s with a bounded %.*s using the known
resource length.
Side_Note: The exact line numbers
may vary. Thinking of an usage like; %.*s with r->res_length to
limit the output to the actual name length. Proper tabs should be
used though.

CVE request:
Please assign a CVE ID for this vulnerability if applicable.
 
Thank you for your attention. Please let me know if you need any
further information.
Best regards,
Fatih Can Yildirim