Bug 48945 (CVE-2004-0003)

Summary: VUL-0: CVE-2004-0003: kernel: DRI: 3 bugs
Product: [Novell Products] SUSE Security Incidents Reporter: Andreas Schwab <schwab>
Component: IncidentsAssignee: Thomas Biege <thomas>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P3 - Medium CC: security-team
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard: CVE-2004-0003: CVSS v2 Base Score: 4.6 (AV:L/AC:L/Au:N/C:P/I:P/A:P)
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: proposed patch from Alan
drm_r128_state.c.diff (drm subdirec)
drm4_r128_state.c.diff (drm4 subdirec)

Description Thomas Biege 2004-01-14 17:35:10 UTC
the following was reported on vendor-sec@. 
Date: Fri, 09 Jan 2004 00:52:05 +0000 
From: Alan Cox <alan@lxorguk.ukuu.org.uk> 
To: vendor-sec@lst.de, akpm@osdl.org 
Subject: [vendor-sec] Direct render infrastructure: multiple apparent 
The DRI code contains lots of gems like 
static int r128_cce_dispatch_write_span( drm_device_t *dev, 
                                         drm_r128_depth_t *depth ) 
        drm_r128_private_t *dev_priv = dev->dev_private; 
        int count, x, y; 
        u32 *buffer; 
        u8 *mask; 
        int i; 
        DRM_DEBUG( "%s\n", __FUNCTION__ ); 
        count = depth->n; 
        if ( copy_from_user( &x, depth->x, sizeof(x) ) ) { 
                return -EFAULT; 
        if ( copy_from_user( &y, depth->y, sizeof(y) ) ) { 
                return -EFAULT; 
        buffer = kmalloc( depth->n * sizeof(u32), GFP_KERNEL ); 
Which has at least 3 bugs in it 
1. depth is already kernel space 
2. depth->n is never checked 
3. depth->n * 4 tends to be a small number if you pick the right n, 
   and it then copies into it. 
Its not the only example at all so folks may wish to audit their DRI 
code extensively. I've not looked at the non Linux paths. 
In the XFree 4.4 devel tree the sis memory allocator for the non sisfb 
paths is also not robust and at the very least I can oops it. Eric 
Anholt knows about this one and will look at it. The radeon mem code 
looks similar to the SIS but I've not attacked that. 
Only the sis memory allocator in XFree 4.4 rc is public knowledge. 
See also however a seperate linux-kernel posting suggesting bugs in the 
gamma driver about user/kernel copying, and also in vt.c 
Date: Mon, 12 Jan 2004 21:20:40 +0000 
From: Alan Cox <alan@lxorguk.ukuu.org.uk> 
To: vendor-sec@lst.de 
Subject: [vendor-sec] Update on DRI holes 
For the r128 driver the hole is public know. My email trying to 
find a maintainer tipped off too many people. Its unmaintained 
so its basically "public, vendor problem" 
You need an r128 card and console to exploit it and since it 
seems to allow only kmalloc type overruns its extremely hard to 
see how to get root out of it. 
Comment 1 Thomas Biege 2004-01-14 17:35:10 UTC
<!-- SBZ_reproduce  -->
Comment 2 Thomas Biege 2004-01-15 20:18:41 UTC
Created attachment 15651 [details]
proposed patch from Alan
Comment 3 Thomas Biege 2004-01-23 22:47:53 UTC
Comment 4 Hubert Mantel 2004-01-26 21:47:02 UTC
Comment 5 Andreas Schwab 2004-02-13 18:25:21 UTC
<!-- SBZ_reopen -->Reopened by schwab@suse.de at Fri Feb 13 11:25:21 2004, took initial reporter thomas@suse.de to cc
Comment 6 Andreas Schwab 2004-02-13 18:25:21 UTC
What if depth->n is negative?  Looks like the patch is incomplete. 
Comment 7 Thomas Biege 2004-02-13 19:17:28 UTC
Is depth->n signed? 
Otherwise it will not matter. 
Comment 8 Thomas Biege 2004-02-13 19:22:56 UTC
Hm, but count is unsigned... so it can even be negativ if depth->n is a 
unsigned integer. *sigh* 
I will not stop the current kernel update for this. 
I think a fix in our kernel CVS should suffice here. 
I'll inform vendor-sec. 
Thanks Andreas. 
Comment 9 Thomas Biege 2004-02-13 19:31:56 UTC
s/count is unsigned/count is signed/ 
Comment 10 Thomas Biege 2004-02-16 21:11:29 UTC
I'll look into a patch this week. 
Comment 11 Thomas Biege 2004-02-17 23:32:02 UTC
Created attachment 16028 [details]
drm_r128_state.c.diff (drm subdirec)
Comment 12 Thomas Biege 2004-02-17 23:32:48 UTC
Created attachment 16029 [details]
drm4_r128_state.c.diff (drm4 subdirec)
Comment 13 Thomas Biege 2004-02-17 23:33:32 UTC
Both patches were sent to vendor-sec@ yesterday. 
Comment 14 Thomas Biege 2004-03-24 00:57:47 UTC
packages released. 
Comment 15 Stefan Dirsch 2004-03-25 22:55:15 UTC
Found this bugreport with the help of the kernel changelog. Finally we got 
some feedback for this change. BTW, did anybody test this patch? 
I wonder why this guy is affected as the patch is only for the r128 DRM 
driver. Radeon 8000 sounds more like a Radeon chipset ... 
Date: Thu, 25 Mar 2004 15:39:14 +0100 
From: juanignaciosl@yahoo.es 
Reply-To: STTS-FB <stts-fb@suse.de> 
To: jd@suse.de 
Subject: Ticket [20040322990000155] : "Upgrading the kernel causes the 
    screen to freeze for a while" 
    Summary: Upgrading the kernel causes the screen to freeze for a while 
 Salutation: Mr. 
   Language: english 
       Name: Nacho 
       Mail: juanignaciosl@yahoo.es 
   Language: english 
Packagename: kernel update 
  Component: Update Problems 
Productname: SUSE LINUX 
Versionname: SUSE LINUX 9.0 professional 
   Platform: i386 
   Severity: Minor bug: Work is hindered unnecessarily 
Description hardware: 
Radeon 8000 
Description how to reproduce: 
1. How to reproduce: 
Upgrade the kernel to the one who corrected some DRI bugs (the one delivered 
past week, I can't remember the exact version). 
2. This is not working: 
Screen output freeze for a moment (some miliseconds) apparently randomly. I 
realized playing Armagetron, but later I saw it 
+happens continously; for example, if I just move the mouse on the desktop it 
sometimes stops. This is particulary molest in 
3. Error messages and logfiles 
I have searched for errors or warnings in XFree log files, but there's nothing 
extrange there. No error message is displayed 
+on screen. 
Comment 16 Thomas Biege 2009-10-13 19:51:07 UTC
CVE-2004-0003: CVSS v2 Base Score: 4.6 (AV:L/AC:L/Au:N/C:P/I:P/A:P)