linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] drm: Fix use-after-free read in drm_getunique()
@ 2021-06-08 11:04 Desmond Cheong Zhi Xi
  2021-06-08 16:20 ` Daniel Vetter
  0 siblings, 1 reply; 2+ messages in thread
From: Desmond Cheong Zhi Xi @ 2021-06-08 11:04 UTC (permalink / raw)
  To: maarten.lankhorst, mripard, tzimmermann, airlied, daniel
  Cc: Desmond Cheong Zhi Xi, dri-devel, linux-kernel, skhan, gregkh,
	linux-kernel-mentees, syzbot+c3a706cec1ea99e1c693

There is a time-of-check-to-time-of-use error in drm_getunique() due
to retrieving file_priv->master prior to locking the device's master
mutex.

An example can be seen in the crash report of the use-after-free error
found by Syzbot:
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803

In the report, the master pointer was used after being freed. This is
because another process had acquired the device's master mutex in
drm_setmaster_ioctl(), then overwrote fpriv->master in
drm_new_set_master(). The old value of fpriv->master was subsequently
freed before the mutex was unlocked.

To fix this, we lock the device's master mutex before retrieving the
pointer from from fpriv->master. This patch passes the Syzbot
reproducer test.

Reported-by: syzbot+c3a706cec1ea99e1c693@syzkaller.appspotmail.com
Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
---

In this patch, I made the assumption that dev and file_priv->master->dev refer to the same struct drm_device*, and from my test runs this seemed to be the case. If this was a wrong assumption to make, please let me know.

 drivers/gpu/drm/drm_ioctl.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index d273d1a8603a..495a4767a443 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -118,17 +118,18 @@ int drm_getunique(struct drm_device *dev, void *data,
 		  struct drm_file *file_priv)
 {
 	struct drm_unique *u = data;
-	struct drm_master *master = file_priv->master;
+	struct drm_master *master;
 
-	mutex_lock(&master->dev->master_mutex);
+	mutex_lock(&dev->master_mutex);
+	master = file_priv->master;
 	if (u->unique_len >= master->unique_len) {
 		if (copy_to_user(u->unique, master->unique, master->unique_len)) {
-			mutex_unlock(&master->dev->master_mutex);
+			mutex_unlock(&dev->master_mutex);
 			return -EFAULT;
 		}
 	}
 	u->unique_len = master->unique_len;
-	mutex_unlock(&master->dev->master_mutex);
+	mutex_unlock(&dev->master_mutex);
 
 	return 0;
 }
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] drm: Fix use-after-free read in drm_getunique()
  2021-06-08 11:04 [PATCH] drm: Fix use-after-free read in drm_getunique() Desmond Cheong Zhi Xi
@ 2021-06-08 16:20 ` Daniel Vetter
  0 siblings, 0 replies; 2+ messages in thread
From: Daniel Vetter @ 2021-06-08 16:20 UTC (permalink / raw)
  To: Desmond Cheong Zhi Xi
  Cc: maarten.lankhorst, mripard, tzimmermann, airlied, daniel,
	dri-devel, linux-kernel, skhan, gregkh, linux-kernel-mentees,
	syzbot+c3a706cec1ea99e1c693

On Tue, Jun 08, 2021 at 07:04:36PM +0800, Desmond Cheong Zhi Xi wrote:
> There is a time-of-check-to-time-of-use error in drm_getunique() due
> to retrieving file_priv->master prior to locking the device's master
> mutex.
> 
> An example can be seen in the crash report of the use-after-free error
> found by Syzbot:
> https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803
> 
> In the report, the master pointer was used after being freed. This is
> because another process had acquired the device's master mutex in
> drm_setmaster_ioctl(), then overwrote fpriv->master in
> drm_new_set_master(). The old value of fpriv->master was subsequently
> freed before the mutex was unlocked.
> 
> To fix this, we lock the device's master mutex before retrieving the
> pointer from from fpriv->master. This patch passes the Syzbot
> reproducer test.
> 
> Reported-by: syzbot+c3a706cec1ea99e1c693@syzkaller.appspotmail.com
> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>

Very nice debug work, thanks a lot!

> ---
> 
> In this patch, I made the assumption that dev and file_priv->master->dev
> refer to the same struct drm_device*, and from my test runs this seemed
> to be the case. If this was a wrong assumption to make, please let me
> know.

Yup that's correct.

Patch applied to drm-misc-fixes and cc: stable added so it gets
backported.

Cheers, Daniel

> 
>  drivers/gpu/drm/drm_ioctl.c | 9 +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index d273d1a8603a..495a4767a443 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -118,17 +118,18 @@ int drm_getunique(struct drm_device *dev, void *data,
>  		  struct drm_file *file_priv)
>  {
>  	struct drm_unique *u = data;
> -	struct drm_master *master = file_priv->master;
> +	struct drm_master *master;
>  
> -	mutex_lock(&master->dev->master_mutex);
> +	mutex_lock(&dev->master_mutex);
> +	master = file_priv->master;
>  	if (u->unique_len >= master->unique_len) {
>  		if (copy_to_user(u->unique, master->unique, master->unique_len)) {
> -			mutex_unlock(&master->dev->master_mutex);
> +			mutex_unlock(&dev->master_mutex);
>  			return -EFAULT;
>  		}
>  	}
>  	u->unique_len = master->unique_len;
> -	mutex_unlock(&master->dev->master_mutex);
> +	mutex_unlock(&dev->master_mutex);
>  
>  	return 0;
>  }
> -- 
> 2.25.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-06-08 16:21 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-08 11:04 [PATCH] drm: Fix use-after-free read in drm_getunique() Desmond Cheong Zhi Xi
2021-06-08 16:20 ` Daniel Vetter

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).