Re: [PATCH] fs/dlm: fix NULL pointer dereference in __queue_work()

[Alexander Aring]

Hi,

On Thu, Sep 17, 2026 at 3:21 AM Yi Yang <yiyang13@xxxxxxxxxx> wrote:
>
> The rawmsg debugfs file lives as long as its configfs comm entry and
> is independent of the lockspace lifetime, but sending requires the
> lowcomms io_workqueue, which only exists between the creation of the
> first lockspace and the release of the last one (or a lowcomms start
> failure); work_stop() then destroys the workqueues and resets their
> pointers to NULL. Writing rawmsg while lowcomms is not running
> therefore ends up in queue_work() with a NULL io_workqueue:
>
>   BUG: KASAN: null-ptr-deref in __queue_work+0x27/0xf0
>   Read of size 4 at addr 0000000000000100 by task syz.4.3355/21899
>
> Regular sends racing with the last lockspace release have the same
> problem, as work_stop() never waits for senders that hold
> connections_srcu from dlm_lowcomms_new_msg() until their queue_work()
> call.
>

if there is a dlm_lowcomms_new_msg() running when there are no
lockspaces being around this alone is already a problem if this is
really the case.

> Track the workqueues with a workqueues_up flag that senders check
> inside their connections_srcu read-side critical section, and make
> work_stop() clear the flag and call synchronize_srcu() before
> destroying the workqueues. This gates all send entry points
> (including the socket error retransmission path), while the socket
> callback work queueing helpers check the flag as a defence in depth;
> the flag is published with release and read with acquire semantics.
> The rawmsg write now fails with -ENOTCONN.
>

It makes sense that rawmsg fails when lowcomms isn't running.

- Alex