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

knfsd: query filesystem for NFSv4 getattr of FATTR4_MAXNAME

2008-02-25T23:59:21+00:00

mainline: a16e92edcd0a2846455a30823e1bac964e743baa

Without this we always return 2^32-1 as the the maximum namelength.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Andreas Gruenbacher 
CC: Oliver Pinter 
Signed-off-by: Greg Kroah-Hartman

NFS: Fix an Oops in encode_lookup()

2008-02-25T23:59:21+00:00

mainline: 54af3bb543c071769141387a42deaaab5074da55

It doesn't look as if the NFS file name limit is being initialised correctly
in the struct nfs_server. Make sure that we limit whatever is being set in
nfs_probe_fsinfo() and nfs_init_server().

Also ensure that readdirplus and nfs4_path_walk respect our file name
limits.

Signed-off-by: Trond Myklebust 
Signed-off-by: Linus Torvalds 
Acked-by: Neil Brown 
CC: Oliver Pinter 
Signed-off-by: Greg Kroah-Hartman

NFSv2/v3: Fix a memory leak when using -onolock

2008-02-25T23:59:21+00:00

mainline: 5cef338b30c110daf547fb13d99f0c77f2a79fbc

    Neil Brown said:
    > Hi Trond,
    >
    > We found that a machine which made moderately heavy use of
    > 'automount' was leaking some nfs data structures - particularly the
    > 4K allocated by rpc_alloc_iostats.
    > It turns out that this only happens with filesystems with -onolock
    > set.

    > The problem is that if NFS_MOUNT_NONLM is set, nfs_start_lockd doesn't
    > set server->destroy, so when the filesystem is unmounted, the
    > ->client_acl is not shutdown, and so several resources are still
    > held.  Multiple mount/umount cycles will slowly eat away memory
    > several pages at a time.

    Signed-off-by: Trond Myklebust 

Acked-by: Neil Brown 
Signed-off-by: Neil Brown 
CC: Oliver Pinter 
Signed-off-by: Greg Kroah-Hartman

NFS: Fix nfs_reval_fsid()

2008-02-25T23:59:20+00:00

mainline: a0356862bcbeb20acf64bc1a82d28a4c5bb957a7

We don't need to revalidate the fsid on the root directory. It suffices to
revalidate it on the current directory.

Signed-off-by: Trond Myklebust 
Acked-by: Neil Brown 
CC: Oliver Pinter 
Signed-off-by: Greg Kroah-Hartman

knfsd: fix spurious EINVAL errors on first access of new filesystem

2008-02-25T23:59:20+00:00

mainline: ac8587dcb58e40dd336d99d60f852041e06cc3dd

The v2/v3 acl code in nfsd is translating any return from fh_verify() to
nfserr_inval.  This is particularly unfortunate in the case of an
nfserr_dropit return, which is an internal error meant to indicate to
callers that this request has been deferred and should just be dropped
pending the results of an upcall to mountd.

Thanks to Roland  for bug report and data collection.

Cc: Roland 
Acked-by: Andreas Gruenbacher 
Signed-off-by: J. Bruce Fields 
Reviewed-By: NeilBrown 
Signed-off-by: Linus Torvalds 
CC: Oliver Pinter 
Signed-off-by: Greg Kroah-Hartman

NFS: Fix a potential file corruption issue when writing

2008-02-25T23:59:18+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
invalidate_inode_pages2() (typically by calling read()).

The bug was introduced by commit 44b11874ff583b6e766a05856b04f3c492c32b84
"NFS: Separate metadata and page cache revalidation mechanisms"

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

splice: fix user pointer access in get_iovec_page_array() (CVE-2008-0600)

2008-02-11T07:28:08+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

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

2008-02-06T19:43:46+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

vfs: coredumping fix (CVE-2007-6206)

2008-02-06T19:43:45+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:08:26+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