Re: [bug report] Potential order violation in fs/dlm/midcomms.c, between 'dlm_midcomms_addr()' and 'dlm_midcomms_exit()'

[Alexander Aring]

Hi Ginger,

On Thu, Apr 23, 2026 at 1:35 AM Ginger <ginger.jzllee@xxxxxxxxx> wrote:
>
> Dear Linux kernel maintainers,
>
> My research-based static analyzer found a potential atomicity bug
> within the 'fs/dlm' subsystem, more specifically, in
> 'fs/dlm/midcomms.c'.
>
> Kernel version: long-term kernel v6.18.9
>
> Potential concurrent triggering executions:
> T0:
> dlm_midcomms_addr
>     --> node = kmalloc(sizeof(*node))
>     --> hlist_add_head_rcu(&node->hlist, &node_hash[r]); [t0]
>     --> node->debugfs = dlm_create_debug_comms_file(nodeid, node); [t3]
>
> T1:
> dlm_midcomms_exit
>    --> hlist_for_each_entry_rcu(node, &node_hash[i], hlist) [t1]
>    --> dlm_delete_debug_comms_file(node->debugfs); [t2]
>
> In T0, the freshly allocated midcomms_node is first added to the
> globally visible 'node_hash' list, and then has its 'debugfs' field
> set up.
> In this case, in T1, the exit function can first iterate over the
> 'node_hash' list and access a 'debugfs' field that has not been set up
> yet.
> The concurrent buggy order is t0 -> t1 -> t2 -> t3, causing order violation.
>
> Please kindly check at your convenience. Thank you for your time and
> consideration.

Thanks for the report. I looked into it and midcomms_exit() is called
in module init/exit functions. I believe the case above can't happen,
but I created a patch to change the behaviour to initialize the
debugfs field in nodes at first before adding it to the node_hash.
This avoids such an issue in potential future changes.

Thanks.

- Alex