Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Aug 2001 02:21:18 -0700 (PDT)
From:      Scott Renfro <scott@renfro.org>
To:        FreeBSD-gnats-submit@freebsd.org
Subject:   ports/30120: [PATCH] Serious bug in security/cfs (data loss)
Message-ID:  <200108270921.f7R9LIR59447@renfro.org>

next in thread | raw e-mail | index | archive | help

>Number:         30120
>Category:       ports
>Synopsis:       [PATCH] Serious bug in security/cfs (data loss)
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-ports
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Aug 27 02:30:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Scott Renfro
>Release:        FreeBSD 4.3-STABLE i386
>Organization:
n/a
>Environment:
System: FreeBSD renfro.org 4.3-STABLE FreeBSD 4.3-STABLE #1: Sun Aug 5 13:27:32 PDT 2001 scott@renfro.org:/usr/src/sys/compile/FWGW4 i386


>Description:

Martin Forssen <maf@tkrat.org> and I have each independently found a
serious bug that leads to data loss in Matt Blaze's otherwise excellent
crypto-filesystem.  This affects all recent versions of cfs that I
checked, including cfs-1.4.1, the current release.

When appending to the file with a write that is less than the cfs
blocksize (8 characters), if the resulting filesize is a multiple of the
cfs blocksize, the write is, in effect, thrown away.  This results from
the padding scheme in place where a file under these conditions must be
truncated by the cfs blocksize (no padding is required when the data
falls on a boundary).

The fix is pretty simple and a patch is supplied below.  I suspect that
this will be included in cfs at some point (it has already gone to
cfs-users, but with no response as yet), but it would be useful to have
the patch included in the ports tree until that time occurs to reduce
the chance of people losing data.

>How-To-Repeat:

Create a 7 byte file (echo "123456" > t.txt) on a cfs filesystem.
Append one byte to the file (echo "" > t.txt).  The resulting file is
still just 7 bytes long.E

For me this shows up quite regularly when procmail writes new mail into
my mbox files -- the leading 'F' in the "^From " header is dropped; yes,
this means that messages 'disappear' and/or are merged into other
messages -- yech.

>Fix:

Add this patch from Martin as patch-ag (or whatever the next available
patch file name is).

--- cfs_fh.c.orig	Mon Aug 27 01:47:52 2001
+++ cfs_fh.c	Mon Aug 27 01:48:41 2001
@@ -177,6 +177,13 @@
 		perror("write");
 		return -1;
 	}
+	/* due to the way the file is padded we may actually have to
+	   truncate it here. This happens when the write is at the end of
+	   the file, is shorter than CFSBLOCK and brings the file to a length
+	   which is evenly dividable by CFSBLOCK */
+	if (offset+len > dtov(sb.st_size) && vtod(offset+len) < sb.st_size) {
+	  ftruncate(fd, vtod(offset+len));
+	}
 	/* iolen may contain CFSBLOCK extra chars */
 	return(dtov(iolen)-fronterr);
 }


>Release-Note:
>Audit-Trail:
>Unformatted:

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108270921.f7R9LIR59447>