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

Hey Greg,
Nice to meet you...
> 日時：2026/03/11 水 15:42
> 件名：Re: [vs] DLM debugfs information disclosure via non-null-terminated resource name
> 
> 
> On Wed, Mar 11, 2026 at 10:31:22AM +0900, [email protected] wrote:
> > Dear maintainers,
> > There is an possible information disclosure vulnerability in the DLM
> > subsystem's debugfs interface.
> 
> debugfs is, by default, only readable by root, and contains loads of
> stuff like this, as it's full of debug information on the system.  So
> much so that many systems do not enable it in their kernels, and others
> do not mount it at all.  So it's not really a problem overall from a
> security point of view.
> 
> > 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.
> 
> That's not good, can you just send a patch for this to the developers
> and mailing list and they can apply it like normal?
> 
> thanks,
> 
> greg k-h
> 
While debugfs is indeed root-only and often disabled, this vulnerability specifically targets environments that do enable it and cannot migrate to userspace coordination systems like ZooKeeper or Redis due to resource constraints or legacy requirements. In those clustered environments (e.g., HPC, Pacemaker/DRBD setups), DLM is actively used, debugfs is present, and local root access can be chained with this leak to bypass KASLR and facilitate further exploitation. So while the overall risk is low, the impact in the specific niche where this code actually runs is real.
On top of this, I would also suggest you looking at things i can`t even spell it`s name right once; IBM s390x architectures like(IBM Z/LinuxONE). These systems cost like hundreds of thousands to $15M+, and they power the world basically[Not an IBM advertisement btw, just some sprinkles]. 
On these platforms, stability and backward compatibility is nirvana dude,and you can't just "rewrite everything to use ZooKeeper". or build your own program[Was it chubby?chobby?chobani maybe idk] like Google did because they can. The kernel DLM is on the environments built and relied upon, debugfs is often present. A KASLR bypass on these systems isn't just an academic exercise... It's a real domino step towards to an infrastructure that literally cannot afford downtime, but still, some device like this somewhere in the world probably depends more or less on what you're currently probably laughing at, anyways...
So in short while this may seem like "just another debugfs something something something" from a desktop Linux perspective, the impact profile changes dramatically when you consider where this code actually runs in production.
Also, i am not going to write or commit an patch, i wrote somethings about that but decision to commit/implement is something i don`t care at the moment.

Thanks,
Fatih Can Yildirim

> 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 
> 
> 


> ----- 引用元メッセージ -----
> 
> From："Greg KH" <[email protected]>
> To："[email protected]" <[email protected]>
> Cc："[email protected]" <[email protected]>; "[email protected]" <[email protected]>; "[email protected]" <[email protected]>; "[email protected]" <[email protected]>
> 日時：2026/03/11 水 15:42
> 件名：Re: [vs] DLM debugfs information disclosure via non-null-terminated resource name
> 
> 
> On Wed, Mar 11, 2026 at 10:31:22AM +0900, [email protected] wrote:
> > Dear maintainers,
> > There is an possible information disclosure vulnerability in the DLM
> > subsystem's debugfs interface.
> 
> debugfs is, by default, only readable by root, and contains loads of
> stuff like this, as it's full of debug information on the system.  So
> much so that many systems do not enable it in their kernels, and others
> do not mount it at all.  So it's not really a problem overall from a
> security point of view.
> 
> > 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.
> 
> That's not good, can you just send a patch for this to the developers
> and mailing list and they can apply it like normal?
> 
> thanks,
> 
> greg k-h
>