Re: [PATCH v1] auxdisplay: linedisp: prepare message before registration

[Andy Shevchenko]

On Sun, Sep 13, 2026 at 12:11:52AM +0800, Yibo Tan wrote:
> Since the line-display attachment support was added, linedisp_register()
> has displayed its initial message before calling device_add().  The
> HT16K33, MAX6959 and GPIO segment drivers implement display updates with
> delayed work, so that display operation can publish driver-owned work
> before the final fallible registration step.
> 
> If device_add() fails, the registration error path releases the display
> buffers and the caller's probe failure releases its managed private data.
> The admitted worker can then access both freed objects.  In an HT16K33
> KASAN reproducer, a real device_add() -EEXIST failure produced a
> slab-use-after-free first in __pwq_activate_work() and then in
> ht16k33_seg7_update().
> 
> The vulnerable kernel queued and executed the freed HT16K33 work in three
> of three runs.  With this change, the same three runs reached the same
> device_add() failure without queuing the update and produced no KASAN,
> WARNING, Oops or panic.
> 
> Separate message preparation from the hardware update.  Prepare the
> initial message before registering the device or attribute groups, and
> only invoke the non-failing update after registration succeeds.  Apply the
> same ordering to linedisp_attach(), which has the same static pattern but
> currently has no in-tree caller.

Yeah, but this will fix only work queueing and not the whole issue as was
earlier noted (about allocation of the private data in the driver and using
it inside the auxdisplay core. Can we rather redo the _register() / _unregister()
APIs to follow the design that is used, for instance, in IIO subsystem?

-- 
With Best Regards,
Andy Shevchenko