Alan mentioned it at the botom of another mail. 
(It triggers a crash/kernel oops) 
 
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 
vulnerabilities 
 
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; 
        RING_LOCALS; 
        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 
 
 
Alan