| Message ID | 1663235055-3081-3-git-send-email-quic_deesin@quicinc.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | rpmsg_char/ctrl driver fixes | expand |
On 9/15/2022 2:44 AM, Deepak Kumar Singh wrote: > Call to rpmsg_ctrldev_ioctl() and rpmsg_ctrldev_remove() must be synchronized. > In present code rpmsg_ctrldev_remove() is not protected with lock, therefore > new char device creation can succeed through rpmsg_ctrldev_ioctl() call. At the > same time call to rpmsg_ctrldev_remove() funtion for ctrl device removal will nit: s/funtion/function/ > free associated rpdev device. As char device creation already succeeded, user > space is free to issue open() call which maps to rpmsg_create_ept() in kernel. > rpmsg_create_ept() function tries to reference rpdev which has already been > freed through rpmsg_ctrldev_remove(). Issue is predominantly seen in aggressive > reboot tests where rpmsg_ctrldev_ioctl() and rpmsg_ctrldev_remove() can race with > each other. > > Adding lock in rpmsg_ctrldev_remove() avoids any new char device creation > throught rpmsg_ctrldev_ioctl() while remove call is already in progress. nit: s/throught/through/ > > Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com> > --- > drivers/rpmsg/rpmsg_ctrl.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/rpmsg/rpmsg_ctrl.c b/drivers/rpmsg/rpmsg_ctrl.c > index 107da70..4332538 100644 > --- a/drivers/rpmsg/rpmsg_ctrl.c > +++ b/drivers/rpmsg/rpmsg_ctrl.c > @@ -194,10 +194,12 @@ static void rpmsg_ctrldev_remove(struct rpmsg_device *rpdev) > struct rpmsg_ctrldev *ctrldev = dev_get_drvdata(&rpdev->dev); > int ret; > > + mutex_lock(&ctrldev->ctrl_lock); > /* Destroy all endpoints */ > ret = device_for_each_child(&ctrldev->dev, NULL, rpmsg_chrdev_eptdev_destroy); > if (ret) > dev_warn(&rpdev->dev, "failed to nuke endpoints: %d\n", ret); > + mutex_unlock(&ctrldev->ctrl_lock); > > cdev_device_del(&ctrldev->cdev, &ctrldev->dev); > put_device(&ctrldev->dev);
diff --git a/drivers/rpmsg/rpmsg_ctrl.c b/drivers/rpmsg/rpmsg_ctrl.c index 107da70..4332538 100644 --- a/drivers/rpmsg/rpmsg_ctrl.c +++ b/drivers/rpmsg/rpmsg_ctrl.c @@ -194,10 +194,12 @@ static void rpmsg_ctrldev_remove(struct rpmsg_device *rpdev) struct rpmsg_ctrldev *ctrldev = dev_get_drvdata(&rpdev->dev); int ret; + mutex_lock(&ctrldev->ctrl_lock); /* Destroy all endpoints */ ret = device_for_each_child(&ctrldev->dev, NULL, rpmsg_chrdev_eptdev_destroy); if (ret) dev_warn(&rpdev->dev, "failed to nuke endpoints: %d\n", ret); + mutex_unlock(&ctrldev->ctrl_lock); cdev_device_del(&ctrldev->cdev, &ctrldev->dev); put_device(&ctrldev->dev);
Call to rpmsg_ctrldev_ioctl() and rpmsg_ctrldev_remove() must be synchronized. In present code rpmsg_ctrldev_remove() is not protected with lock, therefore new char device creation can succeed through rpmsg_ctrldev_ioctl() call. At the same time call to rpmsg_ctrldev_remove() funtion for ctrl device removal will free associated rpdev device. As char device creation already succeeded, user space is free to issue open() call which maps to rpmsg_create_ept() in kernel. rpmsg_create_ept() function tries to reference rpdev which has already been freed through rpmsg_ctrldev_remove(). Issue is predominantly seen in aggressive reboot tests where rpmsg_ctrldev_ioctl() and rpmsg_ctrldev_remove() can race with each other. Adding lock in rpmsg_ctrldev_remove() avoids any new char device creation throught rpmsg_ctrldev_ioctl() while remove call is already in progress. Signed-off-by: Deepak Kumar Singh <quic_deesin@quicinc.com> --- drivers/rpmsg/rpmsg_ctrl.c | 2 ++ 1 file changed, 2 insertions(+)