A race condition may occur if the user physically removes the
pcmcia device while calling open() for this char device node.

This is a race condition between the scr24x_open() function and
the scr24x_remove() function, which may eventually result in UAF.

So, add a mutex to the scr24x_open() and scr24x_remove() functions
to avoid race contidion of krefs.

Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
 drivers/char/pcmcia/scr24x_cs.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/char/pcmcia/scr24x_cs.c b/drivers/char/pcmcia/scr24x_cs.c
index 1bdce08fae3d..319e8d79048e 100644
--- a/drivers/char/pcmcia/scr24x_cs.c
+++ b/drivers/char/pcmcia/scr24x_cs.c
@@ -76,8 +76,10 @@ static int scr24x_open(struct inode *inode, struct file *filp)
 	struct scr24x_dev *dev = container_of(inode->i_cdev,
 				struct scr24x_dev, c_dev);
 
+	mutex_lock(&dev->lock);
 	kref_get(&dev->refcnt);
 	filp->private_data = dev;
+	mutex_unlock(&dev->lock);
 
 	return stream_open(inode, filp);
 }
@@ -298,9 +300,10 @@ static void scr24x_remove(struct pcmcia_device *link)
 	cdev_del(&dev->c_dev);
 	clear_bit(dev->devno, scr24x_minors);
 	dev->dev = NULL;
-	mutex_unlock(&dev->lock);
 
 	kref_put(&dev->refcnt, scr24x_delete);
+
+	mutex_unlock(&dev->lock);
 }
 
 static const struct pcmcia_device_id scr24x_ids[] = {
-- 
2.25.1

On Fri, Sep 16, 2022, at 7:00 AM, Hyunwoo Kim wrote:
> @@ -298,9 +300,10 @@ static void scr24x_remove(struct pcmcia_device *link)
>  	cdev_del(&dev->c_dev);
>  	clear_bit(dev->devno, scr24x_minors);
>  	dev->dev = NULL;
> -	mutex_unlock(&dev->lock);
> 
>  	kref_put(&dev->refcnt, scr24x_delete);
> +
> +	mutex_unlock(&dev->lock);
>  }

This appears to introduce a new use-after-free, when the kref_put()
frees the 'dev' structure and you unlock the mutex in that structure
afterwards.

       Arnd

On Fri, Sep 16, 2022 at 08:59:44AM +0200, Arnd Bergmann wrote:
> This appears to introduce a new use-after-free, when the kref_put()
> frees the 'dev' structure and you unlock the mutex in that structure
> afterwards.

yes. Every patch I've submitted has this issue.
I'll replace the mutex with a global variable and submit a v2 patch that fixes other issues.