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

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

[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 

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

[Greg KH]

On Wed, Mar 11, 2026 at 10:31:22AM +0900, can-yildirim@ymail.ne.jp 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

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

[can-yildirim]

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, can-yildirim@ymail.ne.jp 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" <gregkh@linuxfoundation.org>
> To："can-yildirim@ymail.ne.jp" <can-yildirim@ymail.ne.jp>
> Cc："security@kernel.org" <security@kernel.org>; "gfs2@lists.linux.dev" <gfs2@lists.linux.dev>; "aahringo@redhat.com" <aahringo@redhat.com>; "teigland@redhat.com" <teigland@redhat.com>
> 日時：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, can-yildirim@ymail.ne.jp 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
> 

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

[Greg KH]

On Wed, Mar 11, 2026 at 07:26:54PM +0900, can-yildirim@ymail.ne.jp wrote:
> Hey Greg,
> Nice to meet you...

Hi, and note, why the [vs] in the subject line?  This isn't vendor-sec,
that list is long gone.  What caused that to show up here?

> > 日時：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, can-yildirim@ymail.ne.jp 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.

If you have local root access, heck, just local access, KASLR is
trivially leaked, that is not what KASLR is trying to protect from at
all.

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

I do not understand what you are trying to say here at all, sorry.

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

Then those production systems have worse problems if they are letting a
local root user do whatever they want.

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

Please submit a patch if you feel this is something that should be fixed
up.

thanks,

greg k-h