When remote host goes down glink char device channel is freed,
At the same time user space apps can still try to open/poll rpmsg
char device which will result in calling rpmsg_create_ept. This may
cause reference to already freed context of glink chardev channel and
result in below crash signatures -
1)
rpmsg_create_ept+0x40/0xa0
rpmsg_eptdev_open+0x88/0x138
chrdev_open+0xc4/0x1c8
do_dentry_open+0x230/0x378
2)
rpmsg_poll+0x5c/0x80
rpmsg_eptdev_poll+0x84/0xa4
do_sys_poll+0x22c/0x5c8
This patch adds proper lock and check condition to avoid such crash.
Signed-off-by: Deepak Kumar Singh <[email protected]>
---
drivers/rpmsg/rpmsg_char.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
index 4f21891..5500dc0 100644
--- a/drivers/rpmsg/rpmsg_char.c
+++ b/drivers/rpmsg/rpmsg_char.c
@@ -75,6 +75,7 @@ int rpmsg_chrdev_eptdev_destroy(struct device *dev, void *data)
struct rpmsg_eptdev *eptdev = dev_to_eptdev(dev);
mutex_lock(&eptdev->ept_lock);
+ eptdev->rpdev = NULL;
if (eptdev->ept) {
rpmsg_destroy_ept(eptdev->ept);
eptdev->ept = NULL;
@@ -126,6 +127,11 @@ static int rpmsg_eptdev_open(struct inode *inode, struct file *filp)
return -EBUSY;
}
+ if (!eptdev->rpdev) {
+ mutex_unlock(&eptdev->ept_lock);
+ return -ENETRESET;
+ }
+
get_device(dev);
/*
@@ -277,7 +283,9 @@ static __poll_t rpmsg_eptdev_poll(struct file *filp, poll_table *wait)
if (!skb_queue_empty(&eptdev->queue))
mask |= EPOLLIN | EPOLLRDNORM;
+ mutex_lock(&eptdev->ept_lock);
mask |= rpmsg_poll(eptdev->ept, filp, wait);
+ mutex_unlock(&eptdev->ept_lock);
return mask;
}
--
2.7.4
Hold ctrl device lock in rpmsg_ctrldev_remove to avoid any
new create ept call to proceed, otherwise new ept creation
and associted char device may suceed. Any further call from
user space for rpmsg_eptdev_open will reference already freed
rpdev and will result in crash. Below crash signature was
observed -
rpmsg_create_ept+0x40/0xa0
rpmsg_eptdev_open+0x88/0x138
chrdev_open+0xc4/0x1c8
do_dentry_open+0x230/0x378
vfs_open+0x3c/0x48
path_openat+0x93c/0xa78
do_filp_open+0x98/0x118
do_sys_openat2+0x90/0x220
do_sys_open+0x64/0x8c
Signed-off-by: Deepak Kumar Singh <[email protected]>
---
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);
--
2.7.4
Quoting Deepak Kumar Singh (2022-09-05 11:55:19)
> When remote host goes down glink char device channel is freed,
> At the same time user space apps can still try to open/poll rpmsg
> char device which will result in calling rpmsg_create_ept. This may
> cause reference to already freed context of glink chardev channel and
> result in below crash signatures -
>
> 1)
> rpmsg_create_ept+0x40/0xa0
> rpmsg_eptdev_open+0x88/0x138
> chrdev_open+0xc4/0x1c8
> do_dentry_open+0x230/0x378
>
> 2)
> rpmsg_poll+0x5c/0x80
> rpmsg_eptdev_poll+0x84/0xa4
> do_sys_poll+0x22c/0x5c8
>
> This patch adds proper lock and check condition to avoid such crash.
Usually it's nice to have a two CPU diagram that shows the problem
scenario with time flowing down and interleaving the calls with
indentation, instead of some callstacks. Can you add that detail here? I
guess it would look like this:
CPU0 CPU1
---- ----
do_sys_poll() chrdev_open()
rpmsg_eptdev_poll() rpmsg_eptdev_open()
rpmsg_create_ept()
rpmsg_poll()
<access old rpdev pointer?>
but I don't immediately understand the problem. Probably showing the
free path and wherever eptdev is set to NULL will help inform better
than a parallel poll and chrdev open.
>
> Signed-off-by: Deepak Kumar Singh <[email protected]>
> ---
Any Fixes tag?
Quoting Deepak Kumar Singh (2022-09-05 11:55:20)
> Hold ctrl device lock in rpmsg_ctrldev_remove to avoid any
> new create ept call to proceed, otherwise new ept creation
> and associted char device may suceed. Any further call from
s/associted/associated/
s/suceed/succeed/
> user space for rpmsg_eptdev_open will reference already freed
rpmsg_eptdev_open()
> rpdev and will result in crash. Below crash signature was
> observed -
>
> rpmsg_create_ept+0x40/0xa0
> rpmsg_eptdev_open+0x88/0x138
> chrdev_open+0xc4/0x1c8
> do_dentry_open+0x230/0x378
> vfs_open+0x3c/0x48
> path_openat+0x93c/0xa78
> do_filp_open+0x98/0x118
> do_sys_openat2+0x90/0x220
> do_sys_open+0x64/0x8c
Again, can you show a CPU diagram for what you're fixing? I think the
problem is device is going away, but chrdev_open() is being called and
that's accessing a device that's on the way out?