linux-stable.git/fs, branch linux-2.6.23.y

NFS: Fix a potential file corruption issue when writing

2008-02-26T00:14:07+00:00

patch 5d47a35600270e7115061cb1320ee60ae9bcb6b8 in mainline.

If the inode is flagged as having an invalid mapping, then we can't rely on
the PageUptodate() flag. Ensure that we don't use the "anti-fragmentation"
write optimisation in nfs_updatepage(), since that will cause NFS to write
out areas of the page that are no longer guaranteed to be up to date.

A potential corruption could occur in the following scenario:

client 1			client 2
===============			===============
				fd=open("f",O_CREAT|O_WRONLY,0644);
				write(fd,"fubar\n",6);	// cache last page
				close(fd);
fd=open("f",O_WRONLY|O_APPEND);
write(fd,"foo\n",4);
close(fd);

				fd=open("f",O_WRONLY|O_APPEND);
				write(fd,"bar\n",4);
				close(fd);
-----
The bug may lead to the file "f" reading 'fubar\n\0\0\0\nbar\n' because
client 2 does not update the cached page after re-opening the file for
write. Instead it keeps it marked as PageUptodate() until someone calls
invaldate_inode_pages2() (typically by calling read()).

Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

splice: fix user pointer access in get_iovec_page_array()

2008-02-11T06:02:37+00:00

patch 712a30e63c8066ed84385b12edbfb804f49cbc44 in mainline.

Commit 8811930dc74a503415b35c4a79d14fb0b408a361 ("splice: missing user
pointer access verification") added the proper access_ok() calls to
copy_from_user_mmap_sem() which ensures we can copy the struct iovecs
from userspace to the kernel.

But we also must check whether we can access the actual memory region
pointed to by the struct iovec to fix the access checks properly.

Signed-off-by: Bastian Blank 
Acked-by: Oliver Pinter 
Cc: Jens Axboe 
Cc: Andrew Morton 
Signed-off-by: Pekka Enberg 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

splice: missing user pointer access verification (CVE-2008-0009/10)

2008-02-08T20:01:52+00:00

patch 8811930dc74a503415b35c4a79d14fb0b408a361 in mainline.

vmsplice_to_user() must always check the user pointer and length
with access_ok() before copying. Likewise, for the slow path of
copy_from_user_mmap_sem() we need to check that we may read from
the user region.

Signed-off-by: Jens Axboe 
Cc: Wojciech Purczynski 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds

vm audit: add VM_DONTEXPAND to mmap for drivers that need it (CVE-2008-0007)

2008-02-08T20:01:45+00:00

Drivers that register a ->fault handler, but do not range-check the
offset argument, must set VM_DONTEXPAND in the vm_flags in order to
prevent an expanding mremap from overflowing the resource.

I've audited the tree and attempted to fix these problems (usually by
adding VM_DONTEXPAND where it is not obvious).

Signed-off-by: Nick Piggin 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

knfsd: Allow NFSv2/3 WRITE calls to succeed when krb5i etc is used.

2008-02-08T20:01:45+00:00

patch ba67a39efde8312e386c6f603054f8945433d91f in mainline.

When RPCSEC/GSS and krb5i is used, requests are padded, typically to a multiple
of 8 bytes.  This can make the request look slightly longer than it
really is.

As of

	f34b95689d2ce001c "The NFSv2/NFSv3 server does not handle zero
		length WRITE request correctly",

the xdr decode routines for NFSv2 and NFSv3 reject requests that aren't
the right length, so krb5i (for example) WRITE requests can get lost.

This patch relaxes the appropriate test and enhances the related comment.

Signed-off-by: Neil Brown 
Signed-off-by: J. Bruce Fields 
Cc: Peter Staubach 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

CIFS: Respect umask when using POSIX mkdir

2008-02-08T20:01:42+00:00

patch a8cd925f74c3b1b6d1192f9e75f9d12cc2ab148a in mainline.

[CIFS] Respect umask when using POSIX mkdir

When making a directory with POSIX mkdir calls, cifs_mkdir does not
respect the umask.  This patch causes the new POSIX mkdir to create with
the right mode

Signed-off-by: Jeff Layton 
Signed-off-by: Steve French 
Cc: maximilian attems 
Signed-off-by: Greg Kroah-Hartman

vfs: coredumping fix (CVE-2007-6206)

2008-02-08T20:01:34+00:00

vfs: coredumping fix

patch c46f739dd39db3b07ab5deb4e3ec81e1c04a91af in mainline

fix: http://bugzilla.kernel.org/show_bug.cgi?id=3043

only allow coredumping to the same uid that the coredumping
task runs under.

Signed-off-by: Ingo Molnar 
Acked-by: Alan Cox 
Acked-by: Christoph Hellwig 
Acked-by: Al Viro 
Signed-off-by: Linus Torvalds 
Cc: maximilian attems 
Signed-off-by: Greg Kroah-Hartman

Use access mode instead of open flags to determine needed permissions (CVE-2008-0001)

2008-01-14T20:17:39+00:00

patch 974a9f0b47da74e28f68b9c8645c3786aa5ace1a in mainline

Way back when (in commit 834f2a4a1554dc5b2598038b3fe8703defcbe467, aka
"VFS: Allow the filesystem to return a full file pointer on open intent"
to be exact), Trond changed the open logic to keep track of the original
flags to a file open, in order to pass down the the intent of a dentry
lookup to the low-level filesystem.

However, when doing that reorganization, it changed the meaning of
namei_flags, and thus inadvertently changed the test of access mode for
directories (and RO filesystem) to use the wrong flag.  So fix those
test back to use access mode ("acc_mode") rather than the open flag
("flag").

Issue noticed by Bill Roman at Datalight.

Reported-and-tested-by: Bill Roman 
Acked-by: Trond Myklebust 
Acked-by: Al Viro 
Cc: Christoph Hellwig 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

XFS: Make xfsbufd threads freezable

2007-12-14T17:51:17+00:00

patch 978c7b2ff49597ab76ff7529a933bd366941ac25 in mainline

Fix breakage caused by commit 831441862956fffa17b9801db37e6ea1650b0f69
that did not introduce the necessary call to set_freezable() in
xfs/linux-2.6/xfs_buf.c .

SGI-PV: 974224
SGI-Modid: xfs-linux-melb:xfs-kern:30203a

Signed-off-by: Rafael J. Wysocki 
Signed-off-by: David Chinner 
Signed-off-by: Lachlan McIlroy 
Cc: Oliver Pintr 
Signed-off-by: Greg Kroah-Hartman

reiserfs: don't drop PG_dirty when releasing sub-page-sized dirty file

2007-11-26T17:42:29+00:00

patch c06a018fa5362fa9ed0768bd747c0fab26bc8849 in mainline.

This is not a new problem in 2.6.23-git17.  2.6.22/2.6.23 is buggy in the
same way.

Reiserfs could accumulate dirty sub-page-size files until umount time. 
They cannot be synced to disk by pdflush routines or explicit `sync'
commands.  Only `umount' can do the trick.

The direct cause is: the dirty page's PG_dirty is wrongly _cleared_.
Call trace:
	 [] cancel_dirty_page+0xd0/0xf0
	 [] :reiserfs:reiserfs_cut_from_item+0x660/0x710
	 [] :reiserfs:reiserfs_do_truncate+0x271/0x530
	 [] :reiserfs:reiserfs_truncate_file+0xfd/0x3b0
	 [] :reiserfs:reiserfs_file_release+0x1e0/0x340
	 [] __fput+0xcc/0x1b0
	 [] fput+0x16/0x20
	 [] filp_close+0x56/0x90
	 [] sys_close+0xad/0x110
	 [] system_call+0x7e/0x83

Fix the bug by removing the cancel_dirty_page() call. Tests show that
it causes no bad behaviors on various write sizes.

=== for the patient ===
Here are more detailed demonstrations of the problem.

1) the page has both PG_dirty(D)/PAGECACHE_TAG_DIRTY(d) after being written to;
   and then only PAGECACHE_TAG_DIRTY(d) remains after the file is closed.

------------------------------ screen 0 ------------------------------
[T0] root /home/wfg# cat > /test/tiny
[T1] hi
[T2] root /home/wfg#

------------------------------ screen 1 ------------------------------
[T1] root /home/wfg# echo /test/tiny > /proc/filecache
[T1] root /home/wfg# cat /proc/filecache
     # file /test/tiny
     # flags R:referenced A:active M:mmap U:uptodate D:dirty W:writeback O:owner B:buffer d:dirty w:writeback
     # idx   len     state   refcnt
     0       1       ___UD__Bd_      2
[T2] root /home/wfg# cat /proc/filecache
     # file /test/tiny
     # flags R:referenced A:active M:mmap U:uptodate D:dirty W:writeback O:owner B:buffer d:dirty w:writeback
     # idx   len     state   refcnt
     0       1       ___U___Bd_      2

2) note the non-zero 'cancelled_write_bytes' after /tmp/hi is copied.

------------------------------ screen 0 ------------------------------
[T0] root /home/wfg# echo hi > /tmp/hi
[T1] root /home/wfg# cp /tmp/hi /dev/stdin /test
[T2] hi
[T3] root /home/wfg#

------------------------------ screen 1 ------------------------------
[T1] root /proc/4397# cd /proc/`pidof cp`
[T1] root /proc/4713# cat io
     rchar: 8396
     wchar: 3
     syscr: 20
     syscw: 1
     read_bytes: 0
     write_bytes: 20480
     cancelled_write_bytes: 4096
[T2] root /proc/4713# cat io
     rchar: 8399
     wchar: 6
     syscr: 21
     syscw: 2
     read_bytes: 0
     write_bytes: 24576
     cancelled_write_bytes: 4096

//Question: the 'write_bytes' is a bit more than expected ;-)

Tested-by: Maxim Levitsky 
Cc: Peter Zijlstra 
Cc: Jeff Mahoney 
Signed-off-by: Fengguang Wu 
Reviewed-by: Chris Mason 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman