Hi Olaf, 
The following was reported on vendor-sec: 
Date: Thu, 22 Jan 2004 13:25:50 +0000 (GMT) 
From: Mark J Cox <mjc@redhat.com> 
To: vendor-sec@lst.de 
Subject: [vendor-sec] CAN-2004-0010 kernel ncpfs roothole 
 
ncpfs allows you to mount volumes of NetWare servers under Linux and to 
print to NetWare print queues and spool NetWare print queues to the Linux 
printing system. 
 
Arjan van de Ven discovered a possible roothole in ncpfs which he shared 
with the maintainer.  He says this has been discussed in public.  No valid 
fix yet from the maintainer.  I gave this CAN-2004-0010. 
 
Thanks, Mark 
-- 
Mark J Cox / Red Hat Security Response Team 
 
----- Forwarded message from Arjan van de Ven 
<arjanv@devserv.devel.redhat.com> ----- 
 
Date: Wed, 21 Jan 2004 23:51:25 +0100 
From: Arjan van de Ven <arjanv@devserv.devel.redhat.com> 
To: vandrove@vc.cvut.cz 
Subject: possible security issue in ncpfs 
 
Hi, 
 
ncp_lookup has the following code in it: 
static struct dentry *ncp_lookup(struct inode *dir, struct dentry *dentry, 
struct nameidata *nd) 
{ 
        struct ncp_server *server = NCP_SERVER(dir); 
        struct inode *inode = NULL; 
        struct ncp_entry_info finfo; 
        int error, res, len = dentry->d_name.len + 1; 
        __u8 __name[len]; 
 
 
where d_name.len is user controlled (in case of rename or following 
symlinks) and can thus be 4Kb on x86. In the case of symlinks the user can 
also control like 2Kb of previously-used stackspace so that you get a 
*controlled* stack overflow, something which can be used to overwrite the 
UID fields in the task struct... to 0. 
 
The practical expoitability is not going to be easy but .. the same was 
thought of mremap and do_brk issues. So I would like to ask you to consider 
to get rid of these variable sized arrays on the stack entirely, since I 
suspect lookup is not the only one that suffers from this issue. 
 
 
Greetings, 
   Arjan van de Ven