Bugzilla – Bug 49100
VUL-0: CVE-2004-0010: ncpfs: buffer overflow
Last modified: 2021-10-12 13:29:41 UTC
The following was reported on vendor-sec:
Date: Thu, 22 Jan 2004 13:25:50 +0000 (GMT)
From: Mark J Cox <email@example.com>
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
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.
Mark J Cox / Red Hat Security Response Team
----- Forwarded message from Arjan van de Ven
Date: Wed, 21 Jan 2004 23:51:25 +0100
From: Arjan van de Ven <firstname.lastname@example.org>
Subject: possible security issue in ncpfs
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;
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.
Arjan van de Ven
<!-- SBZ_reproduce -->
Can you keep an eye on this issue. I think there will be an official update
ok, its a kernel bug. Andi has a/the patch and will commit it.
we need this patch ASAP because we have a coordinated release date for
09.02.2004 and this stuff needs a lot of testing. Bu twho do I tell... :)
Additionally Hubert seems to start updating the kernel source at the moment
and this bug should go in it too.
The fix is already checked in in 2.4 kernel-source CVS head
reassign to Hubert as reminder...
Since the fix is already in CVS, we can close this bug. The only remaining issue
currently is the mremap thing...
<!-- SBZ_reopen -->Reopened by email@example.com at Mon Feb 16 11:37:38 2004
reopen, reassigned for tracking.
Created attachment 16075 [details]
CVE-2004-0010: CVSS v2 Base Score: 7.2 (AV:L/AC:L/Au:N/C:C/I:C/A:C)