Re: [PATCH] Auxiliary display drivers: fix possible race condition

[Andy Shevchenko]

On Sun, May 10, 2026 at 06:06:46PM +0200, Alexander A. Klimov wrote:
> Before linedisp_unregister(), call disable_delayed_work_sync(),
> not just cancel_delayed_work_sync().
> 
> While cancel_delayed_work_sync() cancels queued work and
> awaits running work, it doesn't reject future work, such as
> scheduled by the timer which is set up in linedisp_register().
> This timer may fire just before linedisp_unregister() stops it
> and cause kind of use after free.
> 
> In contrast, disable_delayed_work_sync() also prevents future work.

First of all, split on per-driver basis.
Second, there are not so many users of this API

$ git grep -lw disable_delayed_work_sync | wc
     29      29     882

$ git grep -lw cancel_delayed_work_sync | wc
    826     826   29389

Are many of them prone to the same issue? I don't think so. As far as I read
the code the original variant is fine as long as we guarantee that there may
not be any new work scheduling. In this case the scheduling done whenever we
update the line on the display. This can be initiated via user space.
So the question here is the user space is quiet at that time or not. Seems
not to me. Now, shouldn't just ordering of the unregister and cancellation
of the work fix the issue? (It doesn't seem that the works are doing anything
with the linedisp device.)

Also note there is a bigger issue that had been reported a week or so ago.
The problem is that driver removal may lead to UAF. Fixing that problem may
help to address this one as well for all of the linedisp users (switching to
use managed work cancellation that will be done in time, id est after device
is gone).

-- 
With Best Regards,
Andy Shevchenko