[PATCH] drm: never write to the userspace more data than the caller wants

[PATCH] drm: never write to the userspace more data than the caller wants

[Pavel Roskin]

The amount of data wanted by the userspace caller is encoded in the
ioctl number.  Generic drm ioctls were ignoring it.

As a result, Intel Xorg driver didn't work for i386 userspace on x86_64
kernel on some systems.  sizeof(struct drm_mode_get_connector) is 76
bytes on i686 and 80 bytes on x86_64 due to the tail alignment (the data
positions match).  The userspace was using the 4 bytes after the
structure to hold the result of the ioctl.  Since drm_ioctl() was
copying 80 bytes instead of 76, it was clobbering that data.

A workaround has been committed to xf86-video-intel.

Signed-off-by: Pavel Roskin <proski@gnu.org>
Cc: stable@vger.kernel.org
---
 drivers/gpu/drm/drm_drv.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index e572dd2..8a1c721 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -403,8 +403,11 @@ long drm_ioctl(struct file *filp,
 	}
 	else if ((nr >= DRM_COMMAND_END) || (nr < DRM_COMMAND_BASE)) {
 		ioctl = &drm_ioctls[nr];
+		usize = _IOC_SIZE(cmd);
 		cmd = ioctl->cmd;
-		usize = asize = _IOC_SIZE(cmd);
+		asize = _IOC_SIZE(cmd);
+		if (unlikely(usize > asize))
+			usize = asize;
 	} else
 		goto err_i1;
 

Re: [PATCH] drm: never write to the userspace more data than the caller wants

[Chris Wilson]

On Wed, Oct 16, 2013 at 08:12:35PM -0400, Pavel Roskin wrote:
> The amount of data wanted by the userspace caller is encoded in the
> ioctl number.  Generic drm ioctls were ignoring it.
> 
> As a result, Intel Xorg driver didn't work for i386 userspace on x86_64
> kernel on some systems.  sizeof(struct drm_mode_get_connector) is 76
> bytes on i686 and 80 bytes on x86_64 due to the tail alignment (the data
> positions match).  The userspace was using the 4 bytes after the
> structure to hold the result of the ioctl.  Since drm_ioctl() was
> copying 80 bytes instead of 76, it was clobbering that data.
> 
> A workaround has been committed to xf86-video-intel.
> 
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> Cc: stable@vger.kernel.org

Similar patch:
http://lists.freedesktop.org/archives/dri-devel/2013-October/047412.html
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH] drm: never write to the userspace more data than the caller wants

[Pavel Roskin]

On Thu, 17 Oct 2013 13:26:47 +0100
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> On Wed, Oct 16, 2013 at 08:12:35PM -0400, Pavel Roskin wrote:
> > The amount of data wanted by the userspace caller is encoded in the
> > ioctl number.  Generic drm ioctls were ignoring it.
> > 
> > As a result, Intel Xorg driver didn't work for i386 userspace on
> > x86_64 kernel on some systems.  sizeof(struct
> > drm_mode_get_connector) is 76 bytes on i686 and 80 bytes on x86_64
> > due to the tail alignment (the data positions match).  The
> > userspace was using the 4 bytes after the structure to hold the
> > result of the ioctl.  Since drm_ioctl() was copying 80 bytes
> > instead of 76, it was clobbering that data.
> > 
> > A workaround has been committed to xf86-video-intel.
> > 
> > Signed-off-by: Pavel Roskin <proski@gnu.org>
> > Cc: stable@vger.kernel.org
> 
> Similar patch:
> http://lists.freedesktop.org/archives/dri-devel/2013-October/047412.html
> -Chris

Wow, it's great that you also thought about it!

Your patch does almost the same thing.  There is one difference.  If
the userspace requests more data than the kernel needs, your patch would
trust the userspace and set usize to whatever the user wants.  It would
set asize to the same value, allocating more memory than the driver
wants, up to 16383 bytes.  I don't think it's a good idea for
performance reasons.  My patch would decrease usize rather than increase
asize.

The code for driver-specific ioctls could be fixed too, it's just not
so urgent as fixing a real bug.

That said, I have no format objection against your patch.  It would be
great to have that bug fixed.

-- 
Regards,
Pavel Roskin