linux-kernel - [patch 089/164] drm/radeon: r100/r200 ums: block ability for userspace app to trash 0 page and beyond

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 01 Jul 2010 10:34:35 -0700
From:	Greg KH <gregkh@...e.de>
To:	linux-kernel@...r.kernel.org, stable@...nel.org
Cc:	stable-review@...nel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	Dave Airlie <airlied@...hat.com>
Subject: [patch 089/164] drm/radeon: r100/r200 ums: block ability for userspace app to trash 0 page and beyond

2.6.33-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Dave Airlie <airlied@...hat.com>

commit 566d84d172161cb6c0c4dd834c34abbac6bf7b38 upstream.

radeon's have a special ability to passthrough writes in their internal
memory space directly to PCI, this ability means that if some of the internal
surfaces like the depth buffer point at 0x0, any writes to these will
go directly to RAM at 0x0 via PCI busmastering.

Now mesa used to always emit clears after emitting state, since the
radeon mesa driver was refactored a year or more ago, it was found it
could generate a clear request without ever sending any setup state to the
card. So the clear would attempt to clear the depth buffer at 0x0, which
would overwrite main memory at this point. fs corruption ensues.

Also once one app did this correctly, it would never get set back to 0
making this messy to reproduce.

The kernel should block this from happening as mesa runs without privs,
though it does require the user be connected to the current running X session.

This patch implements a check to make sure the depth offset has been set
before a depth clear occurs and if it finds one it prints a warning and
ignores the depth clear request. There is also a mesa fix to avoid sending
the badness going into mesa.

This only affects r100/r200 GPUs in user modesetting mode.

Signed-off-by: Dave Airlie <airlied@...hat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>

---
 drivers/gpu/drm/radeon/radeon_cp.c    |    1 +
 drivers/gpu/drm/radeon/radeon_drv.h   |    2 ++
 drivers/gpu/drm/radeon/radeon_state.c |    6 ++++++
 3 files changed, 9 insertions(+)

--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -1646,6 +1646,7 @@ static int radeon_do_resume_cp(struct dr
 	radeon_cp_load_microcode(dev_priv);
 	radeon_cp_init_ring_buffer(dev, dev_priv, file_priv);

+	dev_priv->have_z_offset = 0;
 	radeon_do_engine_reset(dev);
 	radeon_irq_set_state(dev, RADEON_SW_INT_ENABLE, 1);

--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -268,6 +268,8 @@ typedef struct drm_radeon_private {

 	u32 scratch_ages[5];

+	int have_z_offset;
+
 	/* starting from here on, data is preserved accross an open */
 	uint32_t flags;		/* see radeon_chip_flags */
 	resource_size_t fb_aper_offset;
--- a/drivers/gpu/drm/radeon/radeon_state.c
+++ b/drivers/gpu/drm/radeon/radeon_state.c
@@ -101,6 +101,7 @@ static __inline__ int radeon_check_and_f
 			DRM_ERROR("Invalid depth buffer offset\n");
 			return -EINVAL;
 		}
+		dev_priv->have_z_offset = 1;
 		break;

 	case RADEON_EMIT_PP_CNTL:
@@ -876,6 +877,11 @@ static void radeon_cp_dispatch_clear(str
 		if (tmp & RADEON_BACK)
 			flags |= RADEON_FRONT;
 	}
+	if (flags & (RADEON_DEPTH|RADEON_STENCIL)) {
+		if (!dev_priv->have_z_offset)
+			printk_once(KERN_ERR "radeon: illegal depth clear request. Buggy mesa detected - please update.\n");
+		flags &= ~(RADEON_DEPTH | RADEON_STENCIL);
+	}

 	if (flags & (RADEON_FRONT | RADEON_BACK)) {

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/