kernel/linux.git/fs, branch v2.6.25.2

fix SMP ordering hole in fcntl_setlk() (CVE-2008-1669)

2008-05-06T23:21:10+00:00

commit 0b2bac2f1ea0d33a3621b27ca68b9ae760fca2e9 upstream. fcntl_setlk()/close() race prevention has a subtle hole - we need to make sure that if we *do* have an fcntl/close race on SMP box, the access to descriptor table and inode->i_flock won't get reordered. As it is, we get STORE inode->i_flock, LOAD descriptor table entry vs. STORE descriptor table entry, LOAD inode->i_flock with not a single lock in common on both sides. We do have BKL around the first STORE, but check in locks_remove_posix() is outside of BKL and for a good reason - we don't want BKL on common path of close(2). Solution is to hold ->file_lock around fcheck() in there; that orders us wrt removal from descriptor table that preceded locks_remove_posix() on close path and we either come first (in which case eviction will be handled by the close side) or we'll see the effect of close and do eviction ourselves. Note that even though it's read-only access, we do need ->file_lock here - rcu_read_lock() won't be enough to order the things. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman

Fix dnotify/close race (CVE-2008-1375)

2008-05-01T21:44:40+00:00

commit 214b7049a7929f03bbd2786aaef04b8b79db34e2 upstream. We have a race between fcntl() and close() that can lead to dnotify_struct inserted into inode's list *after* the last descriptor had been gone from current->files. Since that's the only point where dnotify_struct gets evicted, we are screwed - it will stick around indefinitely. Even after struct file in question is gone and freed. Worse, we can trigger send_sigio() on it at any later point, which allows to send an arbitrary signal to arbitrary process if we manage to apply enough memory pressure to get the page that used to host that struct file and fill it with the right pattern... Signed-off-by: Al Viro Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

aio: io_getevents() should return if io_destroy() is invoked

2008-05-01T21:44:37+00:00

commit e92adcba261fd391591bb63c1703185a04a41554 upstream This patch wakes up a thread waiting in io_getevents if another thread destroys the context. This was tested using a small program that spawns a thread to wait in io_getevents while the parent thread destroys the io context and then waits for the getevents thread to exit. Without this patch, the program hangs indefinitely. With the patch, the program exits as expected. Signed-off-by: Jeff Moyer Cc: Zach Brown Cc: Christopher Smith Cc: Benjamin LaHaise Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

JFFS2: Fix free space leak with in-band cleanmarkers

2008-05-01T21:44:31+00:00

We were accounting for the cleanmarker by calling jffs2_link_node_ref() (without locking!), which adjusted both superblock and per-eraseblock accounting, subtracting the size of the cleanmarker from {jeb,c}->free_size and adding it to {jeb,c}->used_size. But only _then_ were we adding the size of the newly-erased block back to the superblock counts, and we were adding each of jeb->{free,used}_size to the corresponding superblock counts. Thus, the size of the cleanmarker was effectively subtracted from the superblock's free_size _twice_. Fix this, by always adding a full eraseblock size to c->free_size when we've erased a block. And call jffs2_link_node_ref() under the proper lock, while we're at it. Thanks to Alexander Yurchenko and/or Damir Shayhutdinov for (almost) pinpointing the problem. [Backport of commit 014b164e1392a166fe96e003d2f0e7ad2e2a0bb7] Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman

AFS: Do not describe debug parameters with their value

2008-04-16T14:43:48+00:00

Describe debug parameters with their names (and not their values). Signed-off-by: Paul Bolle Signed-off-by: David Howells Signed-off-by: Linus Torvalds

vfs: fix possible deadlock in ext2, ext3, ext4 when using xattrs

2008-04-16T02:35:41+00:00

mb_cache_entry_alloc() was allocating cache entries with GFP_KERNEL. But filesystems are calling this function while holding xattr_sem so possible recursion into the fs violates locking ordering of xattr_sem and transaction start / i_mutex for ext2-4. Change mb_cache_entry_alloc() so that filesystems can specify desired gfp mask and use GFP_NOFS from all of them. Signed-off-by: Jan Kara Reported-by: Dave Jones Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

JFFS2 Fix of panics caused by wrong condition for hole frag creation in write_begin

2008-04-14T22:43:14+00:00

This fixes a regression introduced in commit 205c109a7a96d9a3d8ffe64c4068b70811fef5e8 when switching to write_begin/write_end operations in JFFS2. The page offset is miscalculated, leading to corruption of the fragment lists and subsequently to memory corruption and panics. [ Side note: the bug is a fairly direct result of the naming. Nick was likely misled by the use of "offs", since we tend to use the notion of "offset" not as an absolute position, but as an offset _within_ a page or allocation. Alternatively, a "pgoff_t" is a page index, but not a byte offset - our VM naming can be a bit confusing. So in this case, a VM person would likely have called this a "pos", not an "offs", or perhaps talked about byte offsets rather than page offsets (since it's counted in bytes, not pages). - Linus ] Signed-off-by: Alexey Korolev Signed-off-by: Vasiliy Leonenko Signed-off-by: David Woodhouse Signed-off-by: Linus Torvalds

locks: fix possible infinite loop in fcntl(F_SETLKW) over nfs

2008-04-14T19:22:14+00:00

Miklos Szeredi found the bug: "Basically what happens is that on the server nlm_fopen() calls nfsd_open() which returns -EACCES, to which nlm_fopen() returns NLM_LCK_DENIED. "On the client this will turn into a -EAGAIN (nlm_stat_to_errno()), which in will cause fcntl_setlk() to retry forever." So, for example, opening a file on an nfs filesystem, changing permissions to forbid further access, then trying to lock the file, could result in an infinite loop. And Trond Myklebust identified the culprit, from Marc Eshel and I: 7723ec9777d9832849b76475b1a21a2872a40d20 "locks: factor out generic/filesystem switch from setlock code" That commit claimed to just be reshuffling code, but actually introduced a behavioral change by calling the lock method repeatedly as long as it returned -EAGAIN. We assumed this would be safe, since we assumed a lock of type SETLKW would only return with either success or an error other than -EAGAIN. However, nfs does can in fact return -EAGAIN in this situation, and independently of whether that behavior is correct or not, we don't actually need this change, and it seems far safer not to depend on such assumptions about the filesystem's ->lock method. Therefore, revert the problematic part of the original commit. This leaves vfs_lock_file() and its other callers unchanged, while returning fcntl_setlk and fcntl_setlk64 to their former behavior. Signed-off-by: J. Bruce Fields Tested-by: Miklos Szeredi Cc: Trond Myklebust Cc: Marc Eshel Signed-off-by: Linus Torvalds

Merge branch 'docs' of git://git.lwn.net/linux-2.6

2008-04-11T20:24:16+00:00

* 'docs' of git://git.lwn.net/linux-2.6: Add additional examples in Documentation/spinlocks.txt Move sched-rt-group.txt to scheduler/ Documentation: move rpc-cache.txt to filesystems/ Documentation: move nfsroot.txt to filesystems/ Spell out behavior of atomic_dec_and_lock() in kerneldoc Fix a typo in highres.txt Fixes to the seq_file document Fill out information on patch tags in SubmittingPatches Add the seq_file documentation

Documentation: move nfsroot.txt to filesystems/

2008-04-11T19:18:01+00:00

Documentation/ is a little large, and filesystems/ seems an obvious place for this file. Signed-off-by: J. Bruce Fields Signed-off-by: Jonathan Corbet