Re: [PATCH] rust: serdev: Fix race condition on driver probe fail
From: Markus Probst
Date: Sat Sep 05 2026 - 10:29:24 EST
On Sat, 2026-09-05 at 15:24 +0100, Gary Guo wrote:
> On Sat Sep 5, 2026 at 1:22 AM BST, Markus Probst wrote:
> > On Fri, 2026-09-04 at 23:54 +0000, Markus Probst wrote:
> > > If `Driver::probe` fails, the pointer to the driver data (`PrivateData`)
> > > will first be set to NULL by `drvdata_obtain` and only after that the
> > > serdev device will be closed by Drop. Thus there is a small window in
> > > which the serdev device is still open, but the pointer to the driver data
> > > is NULL. Therefore it is possible that `receive_buf_callback` might try to
> > > access the `active` mutex on a null pointer.
> > It seems, Sashiko found the same issue in a different unrelated place
> > too (while reviewing this patch):
> >
> > https://sashiko.dev/#/patchset/20260905-rust_serdev_fix-v1-1-2ea92b154a6b%40posteo.de
> >
> > Unfortunately, I cannot fix this one so easily, because the serdev
> > device needs to be open for the entire lifetime of the "real" driver
> > data (Driver::Data).
>
> What would go wrong if the device is closed before destroying the driver data?
The driver would still have a handle to the Device and could call
`Device::set_baudrate` for instance. This would be a use-after-free by
itself.
I am currently investigating, if I can only stop rx and leave the
device for transmission open. There seems to be the `CREAD` c_cflag I
can remove from the tty. But I am not sure yet if it guarantees that
receive_buf isn't called anymore.
Thanks
- Markus Probst
>
> Best,
> Gary
Attachment:
signature.asc
Description: This is a digitally signed message part