Bug 556692

Summary: kernel: drm/radeon: r6xx/r7xx possible security issue, system ram access
Product: [Other] Security Response Reporter: Eugene Teo (Security Response) <eteo>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: arozansk, rkhan, talltaurus2002, tao
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-10-19 09:04:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 559577    
Bug Blocks:    

Description Eugene Teo (Security Response) 2010-01-19 04:45:56 UTC 
Description of problem:
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.

Signed-off-by: Jerome Glisse <jglisse>

Reference:
http://lkml.org/lkml/2010/1/18/106
Comment 4 Eugene Teo (Security Response) 2010-01-19 04:57:51 UTC 
This does not affect Red Hat Enterprise Linux 3, 4, 5, and Red Hat Enterprise MRG as these Linux kernels do not have support for this drm device driver.
Comment 13 Jonathan 2010-03-26 20:14:51 UTC 
I am glad to see fedora keeping an eye out on this. The whole bring the GPU out of lockup thing is scaring me too. Because once it's able to bring it out of lockup then it's more open to attacks that aren't identifiable by a frozen computer.
Number two on my this is scary and stupid list is onboard video designed to work with discrete gpu's or hybrid sli. What is horrible about this is they simply disable the vram and use the system ram. Why they didn't design this to force the discrete gpu to handle all the memory and to be plugged to the monitor using it's frame buffer instead of giving the frame buffer to the onboard GPU. That breaks hybrid power where you disable the onboard gpu entirely to save power, but the using a frame buffer in system ram ONLY and ALL THE TIME seems to want to be manipulated into being exploitable.

My huge concerns. Intel wants to be able to bring GPU out of lockup. Intel wants to handle the frame buffer on all this. Intel is asserting rights to these busses and being strange and protective with cross licensing. Everyone else wants to include gpu in every system either on cpu or in a multi chip package. The onboard gpu's aren't capable because of strange ways they use the pci busses. When nearly the exact same chip is capable of 4.8 gtexel/s and 2.4 gpixels/s in discrete form but can only manage 800mega texels and 400 mega pixels in MCP form it's strange. If it's not benefiting the consumer who is it for?

Protect GPU gart with machine guns if necessary. Give options on GPU lockup recovery. None of this stuff will be a concern on shader model 3.0 but 4.0 and 5.0 are extremely suspect. When cpu's lockup the systems crash. They should do the same thing when gpu's lock up.

I'm not an expert on all this but I know enough to be concerned. Even law enforcement doesn't have the right to turn everyone's computers into a crashing flaking rape train. Stick around using the GPU as an attack vector should be coming any time now. It'll get more sophisticated as OpenCL and Direct Compute become more common.