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

[Greg KH <gregkh@linuxfoundation.org>]

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