linux/drivers/gpu/drm, branch mybooklive

drm/i915: Avoid NULL deref in get_pages() unwind after error.

2010-04-01T22:58:47Z

commit 1f2b10131f83f7caa67bf1273cec126b4283015d upstream. Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=15527 NULL pointer dereference in i915_gem_object_save_bit_17_swizzle BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] i915_gem_object_save_bit_17_swizzle+0x5b/0xc0 [i915] Call Trace: [] ? i915_gem_object_put_pages+0x125/0x150 [i915] [] ? i915_gem_object_get_pages+0xf1/0x110 [i915] [] ? i915_gem_object_bind_to_gtt+0xb8/0x2a0 [i915] [] ? drm_mm_get_block_generic+0x4d/0x180 [] ? i915_gem_mmap_gtt_ioctl+0x16d/0x240 [i915] [] ? i915_gem_madvise_ioctl+0x86/0x120 [i915] Signed-off-by: Chris Wilson Reported-by: maciej.rutecki@gmail.com Cc: stable@kernel.org Reviewed-by: Eric Anholt Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman

drm/edid: Unify detailed block parsing between base and extension blocks

2010-04-01T22:58:12Z

commit 9cf00977da092096c7a983276dad8b3002d23a99 upstream. Also fix an embarassing bug in standard timing subblock parsing that would result in an infinite loop. Signed-off-by: Adam Jackson Signed-off-by: Dave Airlie Cc: maximilian attems Signed-off-by: Greg Kroah-Hartman

drm/i915: fix gpio register detection logic for BIOS without VBT

2010-04-01T22:58:02Z

commit 29874f44fbcbc24b231b42c9956f8f9de9407231 upstream. if no VBT is present, crt_ddc_bus will be left at 0, and cause us to use that for the GPIO register offset. That's never a valid register offset, so let the "undefined" value be 0 instead of -1. Signed-off-by: Shaohua Li Signed-off-by: Zhao Yakui Signed-off-by: Eric Anholt [anholt: clarified the commit message a bit] Signed-off-by: Greg Kroah-Hartman

drm/ttm: handle OOM in ttm_tt_swapout

2010-03-15T15:50:12Z

commit 290e55056ec3d25c72088628245d8cae037b30db upstream. - Without this change I get a general protection fault. - Also use PTR_ERR where applicable. Signed-off-by: Maarten Maathuis Reviewed-by: Dave Airlie Acked-by: Thomas Hellstrom Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/i915: Use a dmi quirk to skip a broken SDVO TV output.

2010-03-15T15:50:12Z

commit 6070a4a928f8c92b9fae7d6717ebbb05f425d6b2 upstream. This IBM system has a multi-function SDVO card that reports both VGA and TV, but the system has no TV connector. The TV connector always reported as connected, which would lead to poor modesetting choices. https://bugs.freedesktop.org/show_bug.cgi?id=25787 Signed-off-by: Zhao Yakui Tested-by: Vance Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman

drm/i915: disable TV hotplug status check

2010-03-15T15:49:41Z

commit 8fcc501831aa5b37a4a5a8cd9dc965be3cacc599 upstream. As we removed TV hotplug, don't check its status ever. Reviewed-by: Adam Jackson Signed-off-by: Zhenyu Wang Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman

drm/i915: fix get_core_clock_speed for G33 class desktop chips

2010-03-15T15:49:41Z

commit 43bcd61fae05fc6062b4f117c5adb1a72c9f8c57 upstream. Somehow the case for G33 got dropped while porting from ums code. This made a 400MHz chip into a 133MHz one which resulted in the unnecessary enabling of double wide pipe mode which in turn screwed up the overlay code. Nothing else (than the overlay code) seems to be affected. This fixes fdo.org bug #24835 Signed-off-by: Daniel Vetter Signed-off-by: Eric Anholt Signed-off-by: Greg Kroah-Hartman

drm/radeon: r6xx/r7xx possible security issue, system ram access

2010-03-15T15:49:40Z

commit c8c15ff1e90bfc4a2db1ba77a01b3b2783e723fc upstream This patch workaround a possible security issue which can allow user to abuse drm on r6xx/r7xx hw to access any system ram memory. This patch doesn't break userspace, it detect "valid" old use of CB_COLOR[0-7]_FRAG & CB_COLOR[0-7]_TILE registers and overwritte the address these registers are pointing to with the one of the last color buffer. This workaround will work for old mesa & xf86-video-ati and any old user which did use similar register programming pattern as those (we expect that there is no others user of those ioctl except possibly a malicious one). This patch add a warning if it detects such usage, warning encourage people to update their mesa & xf86-video-ati. New userspace will submit proper relocation. Fix for xf86-video-ati / mesa (this kernel patch is enough to prevent abuse, fix for userspace are to set proper cs stream and avoid kernel warning) : http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=95d63e408cc88b6934bec84a0b1ef94dfe8bee7b http://cgit.freedesktop.org/mesa/mesa/commit/?id=46dc6fd3ed5ef96cda53641a97bc68c3bc104a9f Abusing this register to perform system ram memory is not easy, here is outline on how it could be achieve. First attacker must have access to the drm device and be able to submit command stream throught cs ioctl. Then attacker must build a proper command stream for r6xx/r7xx hw which will abuse the FRAG or TILE buffer to overwrite the GPU GART which is in VRAM. To achieve so attacker as to setup CB_COLOR[0-7]_FRAG or CB_COLOR[0-7]_TILE to point to the GPU GART, then it has to find a way to write predictable value into those buffer (with little cleverness i believe this can be done but this is an hard task). Once attacker have such program it can overwritte GPU GART to program GPU gart to point anywhere in system memory. It then can reusse same method as he used to reprogram GART to overwritte the system ram through the GART mapping. In the process the attacker has to be carefull to not overwritte any sensitive area of the GART table, like ring or IB gart entry as it will more then likely lead to GPU lockup. Bottom line is that i think it's very hard to use this flaw to get system ram access but in theory one can achieve so. Side note: I am not aware of anyone ever using the GPU as an attack vector, nevertheless we take great care in the opensource driver to try to detect and forbid malicious use of GPU. I don't think the closed source driver are as cautious as we are. [bwh: Adjusted context for 2.6.32] Signed-off-by: Jerome Glisse Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: r600/r700 don't test ib if ib initialization fails

2010-03-15T15:49:39Z

commit db96380ea26fcc31ab37189aedeabd12894b1431 upstream If ib initialization failed don't try to test ib as it will result in an oops (accessing NULL ib buffer ptr). [bwh: Adjusted context for 2.6.32] Signed-off-by: Jerome Glisse Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman

drm/radeon/kms: Forbid creation of framebuffer with no valid GEM object

2010-03-15T15:49:39Z

commit 7e71c9e2e7704ebf044d4a964e02fbd2098a173f upstream. This will avoid oops if at later point the fb is use. Trying to create a framebuffer with no valid GEM object is bogus and should be forbidden as this patch does. Signed-off-by: Jerome Glisse Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman