[10266] in bugtraq
PATCH: Fix for linux 2.0.x -ve truncation problem
daemon@ATHENA.MIT.EDU (Chris Wedgwood)
Mon Apr 19 15:01:07 1999
Date: Mon, 19 Apr 1999 11:50:25 +1200
Reply-To: Chris Wedgwood <chris@CYBERNET.CO.NZ>
From: Chris Wedgwood <chris@CYBERNET.CO.NZ>
X-To: Mixter <mixter@POPMAIL.COM>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <Pine.LNX.4.04.9904152047520.620-100000@aviation.net>; from
Mixter on Thu, Apr 15, 1999 at 09:06:42PM +0200
--DocE+STaALJfprDB
Content-Type: text/plain; charset=us-ascii
On Thu, Apr 15, 1999 at 09:06:42PM +0200, Mixter wrote:
> That program you wrote is very scary :)
> Any user can create files on any kind of partition with a
> "negative" size (ie. with wrong file structure information).
> IMO, this is a problem of a linux x86 kernel instruction..
linux-2.0.33:
open("/tmp/blah", O_RDWR|O_CREAT, 0600) = 3
fchmod(3, 0666) = 0
ftruncate(3, 4294067296) = 0
fsync(3) = 0
looking at the 2.0.36 source, there is no check in
fs/open.c:do_truncate so I assume it too is vulnerable (I don't have
a machine spare that I can break to test this on).
Recent linux 2.2.x kernels seem OK:
open("blah", O_RDWR|O_CREAT, 0600) = 3
fchmod(3, 0666) = 0
ftruncate(3, 4294067296) = -1 EINVAL (Invalid argument)
fsync(3) = 0
A patch to fix 2.0.x this is appended below (against 2.0.36). Its
just a cut and paste of the relevant code from recent kernels, I
assume it works, not tested but I can't see how it can fail...
-Chris
--DocE+STaALJfprDB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="2.0.36-do_truncate-fix.patch"
--- linux/fs/open.c~ Sat Nov 30 23:21:19 1996
+++ linux/fs/open.c Mon Apr 19 12:44:47 1999
@@ -68,6 +68,11 @@
int error;
struct iattr newattrs;
+
+ /* Not pretty: "inode->i_size" shouldn't really be "off_t". But it is. */
+ if ((off_t) length < 0)
+ return -EINVAL;
+
down(&inode->i_sem);
newattrs.ia_size = length;
newattrs.ia_valid = ATTR_SIZE | ATTR_CTIME;
--DocE+STaALJfprDB--
