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

proc: restrict access to /proc/PID/io

2011-08-01T20:54:59+00:00

[ upstream commit 1d1221f375c94ef961ba8574ac4f85c8870ddd51 ]

/proc/PID/io may be used for gathering private information.  E.g.  for
openssh and vsftpd daemons wchars/rchars may be used to learn the
precise password length.  Restrict it to processes being able to ptrace
the target process.

ptrace_may_access() is needed to prevent keeping open file descriptor of
"io" file, executing setuid binary and gathering io information of the
setuid'ed process.

Said to be CVE-2011-2495

Signed-off-by: Vasiliy Kulikov 
Signed-off-by: Linus Torvalds 
Signed-off-by: Andi Kleen

mm: prevent concurrent unmap_mapping_range() on the same inode

2011-08-01T20:54:59+00:00

commit 2aa15890f3c191326678f1bd68af61ec6b8753ec upstream.

Michael Leun reported that running parallel opens on a fuse filesystem
can trigger a "kernel BUG at mm/truncate.c:475"

Gurudas Pai reported the same bug on NFS.

The reason is, unmap_mapping_range() is not prepared for more than
one concurrent invocation per inode.  For example:

  thread1: going through a big range, stops in the middle of a vma and
     stores the restart address in vm_truncate_count.

  thread2: comes in with a small (e.g. single page) unmap request on
     the same vma, somewhere before restart_address, finds that the
     vma was already unmapped up to the restart address and happily
     returns without doing anything.

Another scenario would be two big unmap requests, both having to
restart the unmapping and each one setting vm_truncate_count to its
own value.  This could go on forever without any of them being able to
finish.

Truncate and hole punching already serialize with i_mutex.  Other
callers of unmap_mapping_range() do not, and it's difficult to get
i_mutex protection for all callers.  In particular ->d_revalidate(),
which calls invalidate_inode_pages2_range() in fuse, may be called
with or without i_mutex.

This patch adds a new mutex to 'struct address_space' to prevent
running multiple concurrent unmap_mapping_range() on the same mapping.

[ We'll hopefully get rid of all this with the upcoming mm
  preemptibility series by Peter Zijlstra, the "mm: Remove i_mmap_mutex
  lockbreak" patch in particular.  But that is for 2.6.39 ]

Signed-off-by: Miklos Szeredi 
Reported-by: Michael Leun 
Reported-by: Gurudas Pai 
Tested-by: Gurudas Pai 
Acked-by: Hugh Dickins 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen

exec: delay address limit change until point of no return

2011-08-01T20:54:56+00:00

commit dac853ae89043f1b7752875300faf614de43c74b upstream.

Unconditionally changing the address limit to USER_DS and not restoring
it to its old value in the error path is wrong because it prevents us
using kernel memory on repeated calls to this function.  This, in fact,
breaks the fallback of hard coded paths to the init program from being
ever successful if the first candidate fails to load.

With this patch applied switching to USER_DS is delayed until the point
of no return is reached which makes it possible to have a multi-arch
rootfs with one arch specific init binary for each of the (hard coded)
probed paths.

Since the address limit is already set to USER_DS when start_thread()
will be invoked, this redundancy can be safely removed.

Signed-off-by: Mathias Krause 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen

oprofile, dcookies: Fix possible circular locking dependency

2011-08-01T20:54:56+00:00

commit fe47ae7f53e179d2ef6771024feb000cbb86640f upstream.

The lockdep warning below detects a possible A->B/B->A locking
dependency of mm->mmap_sem and dcookie_mutex. The order in
sync_buffer() is mm->mmap_sem/dcookie_mutex, while in
sys_lookup_dcookie() it is vice versa.

Fixing it in sys_lookup_dcookie() by unlocking dcookie_mutex before
copy_to_user().

oprofiled/4432 is trying to acquire lock:
 (&mm->mmap_sem){++++++}, at: [] might_fault+0x53/0xa3

but task is already holding lock:
 (dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (dcookie_mutex){+.+.+.}:
       [] lock_acquire+0xf8/0x11e
       [] mutex_lock_nested+0x63/0x309
       [] get_dcookie+0x30/0x144
       [] sync_buffer+0x196/0x3ec [oprofile]
       [] task_exit_notify+0x16/0x1a [oprofile]
       [] notifier_call_chain+0x37/0x63
       [] __blocking_notifier_call_chain+0x50/0x67
       [] blocking_notifier_call_chain+0x14/0x16
       [] profile_task_exit+0x1a/0x1c
       [] do_exit+0x2a/0x6fc
       [] do_group_exit+0x83/0xae
       [] sys_exit_group+0x17/0x1b
       [] system_call_fastpath+0x16/0x1b

-> #0 (&mm->mmap_sem){++++++}:
       [] __lock_acquire+0x1085/0x1711
       [] lock_acquire+0xf8/0x11e
       [] might_fault+0x80/0xa3
       [] sys_lookup_dcookie+0x104/0x149
       [] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

1 lock held by oprofiled/4432:
 #0:  (dcookie_mutex){+.+.+.}, at: [] sys_lookup_dcookie+0x45/0x149

stack backtrace:
Pid: 4432, comm: oprofiled Not tainted 2.6.39-00008-ge5a450d #9
Call Trace:
 [] print_circular_bug+0xae/0xbc
 [] __lock_acquire+0x1085/0x1711
 [] ? get_parent_ip+0x11/0x42
 [] ? might_fault+0x53/0xa3
 [] lock_acquire+0xf8/0x11e
 [] ? might_fault+0x53/0xa3
 [] ? path_put+0x22/0x27
 [] might_fault+0x80/0xa3
 [] ? might_fault+0x53/0xa3
 [] sys_lookup_dcookie+0x104/0x149
 [] system_call_fastpath+0x16/0x1b

References: https://bugzilla.kernel.org/show_bug.cgi?id=13809
Signed-off-by: Robert Richter 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen

fat: Fix corrupt inode flags when remove ATTR_SYS flag

2011-08-01T20:54:55+00:00

commit 1adffbae22332bb558c2a29de19d9aca391869f6 upstream.

We are clearly missing '~' in fat_ioctl_set_attributes().

Reported-by: Dmitry Dmitriev 
Signed-off-by: OGAWA Hirofumi 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen

UBIFS: fix memory leak on error path

2011-08-01T20:54:54+00:00

commit 812eb258311f89bcd664a34a620f249d54a2cd83 upstream.

UBIFS leaks memory on error path in 'ubifs_jnl_update()' in case of write
failure because it forgets to free the 'struct ubifs_dent_node *dent' object.
Although the object is small, the alignment can make it large - e.g., 2KiB
if the min. I/O unit is 2KiB.

Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen

UBIFS: fix shrinker object count reports

2011-08-01T20:54:54+00:00

commit cf610bf4199770420629d3bc273494bd27ad6c1d upstream.

Sometimes VM asks the shrinker to return amount of objects it can shrink,
and we return the ubifs_clean_zn_cnt in that case. However, it is possible
that this counter is negative for a short period of time, due to the way
UBIFS TNC code updates it. And I can observe the following warnings sometimes:

shrink_slab: ubifs_shrinker+0x0/0x2b7 [ubifs] negative objects to delete nr=-8541616642706119788

This patch makes sure UBIFS never returns negative count of objects.

Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen

UBIFS: fix a rare memory leak in ro to rw remounting path

2011-08-01T20:54:53+00:00

commit eaeee242c531cd4b0a4a46e8b5dd7ef504380c42 upstream.

When re-mounting from R/O mode to R/W mode and the LEB count in the superblock
is not up-to date, because for the underlying UBI volume became larger, we
re-write the superblock. We allocate RAM for these purposes, but never free it.
So this is a memory leak, although very rare one.

Signed-off-by: Artem Bityutskiy 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen

eCryptfs: Allow 2 scatterlist entries for encrypted filenames

2011-08-01T20:54:53+00:00

commit 8d08dab786ad5cc2aca2bf870de370144b78c85a upstream.

The buffers allocated while encrypting and decrypting long filenames can
sometimes straddle two pages. In this situation, virt_to_scatterlist()
will return -ENOMEM, causing the operation to fail and the user will get
scary error messages in their logs:

kernel: ecryptfs_write_tag_70_packet: Internal error whilst attempting
to convert filename memory to scatterlist; expected rc = 1; got rc =
[-12]. block_aligned_filename_size = [272]
kernel: ecryptfs_encrypt_filename: Error attempting to generate tag 70
packet; rc = [-12]
kernel: ecryptfs_encrypt_and_encode_filename: Error attempting to
encrypt filename; rc = [-12]
kernel: ecryptfs_lookup: Error attempting to encrypt and encode
filename; rc = [-12]

The solution is to allow up to 2 scatterlist entries to be used.

Signed-off-by: Tyler Hicks 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen

Fix for buffer overflow in ldm_frag_add not sufficient

2011-08-01T20:54:51+00:00

commit cae13fe4cc3f24820ffb990c09110626837e85d4 upstream.

As Ben Hutchings discovered [1], the patch for CVE-2011-1017 (buffer
overflow in ldm_frag_add) is not sufficient.  The original patch in
commit c340b1d64000 ("fs/partitions/ldm.c: fix oops caused by corrupted
partition table") does not consider that, for subsequent fragments,
previously allocated memory is used.

[1] http://lkml.org/lkml/2011/5/6/407

Reported-by: Ben Hutchings 
Signed-off-by: Timo Warns 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andi Kleen