linux-toradex.git/fs/proc/base.c, branch v3.6.5

proc: do not allow negative offsets on /proc//environ

2012-07-31T00:25:20+00:00

__mem_open() which is called by both /proc//environ and
/proc//mem ->open() handlers will allow the use of negative offsets.
/proc//mem has negative offsets but not /proc//environ.

Clean this by moving the 'force FMODE_UNSIGNED_OFFSET flag' to mem_open()
to allow negative offsets only on /proc//mem.

Signed-off-by: Djalal Harouni 
Cc: Oleg Nesterov 
Cc: Brad Spengler 
Acked-by: Kees Cook 
Cc: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

proc: environ_read() make sure offset points to environment address range

2012-07-31T00:25:20+00:00

Currently the following offset and environment address range check in
environ_read() of /proc//environ is buggy:

  int this_len = mm->env_end - (mm->env_start + src);
  if (this_len <= 0)
    break;

Large or negative offsets on /proc//environ converted to 'unsigned
long' may pass this check since '(mm->env_start + src)' can overflow and
'this_len' will be positive.

This can turn /proc//environ to act like /proc//mem since
(mm->env_start + src) will point and read from another VMA.

There are two fixes here plus some code cleaning:

1) Fix the overflow by checking if the offset that was converted to
   unsigned long will always point to the [mm->env_start, mm->env_end]
   address range.

2) Remove the truncation that was made to the result of the check,
   storing the result in 'int this_len' will alter its value and we can
   not depend on it.

For kernels that have commit b409e578d ("proc: clean up
/proc//environ handling") which adds the appropriate ptrace check and
saves the 'mm' at ->open() time, this is not a security issue.

This patch is taken from the grsecurity patch since it was just made
available.

Signed-off-by: Djalal Harouni 
Cc: Oleg Nesterov 
Cc: Brad Spengler 
Acked-by: Kees Cook 
Cc: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs: add nd_jump_link

2012-07-14T12:35:40+00:00

Add a helper that abstracts out the jump to an already parsed struct path
from ->follow_link operation from procfs.  Not only does this clean up
the code by moving the two sides of this game into a single helper, but
it also prepares for making struct nameidata private to namei.c

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

fs: move path_put on failure out of ->follow_link

2012-07-14T12:35:35+00:00

Currently the non-nd_set_link based versions of ->follow_link are expected
to do a path_put(&nd->path) on failure.  This calling convention is unexpected,
undocumented and doesn't match what the nd_set_link-based instances do.

Move the path_put out of the only non-nd_set_link based ->follow_link
instance into the caller.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

stop passing nameidata to ->lookup()

2012-07-14T12:34:32+00:00

Just the flags; only NFS cares even about that, but there are
legitimate uses for such argument.  And getting rid of that
completely would require splitting ->lookup() into a couple
of methods (at least), so let's leave that alone for now...

Signed-off-by: Al Viro

stop passing nameidata * to ->d_revalidate()

2012-07-14T12:34:14+00:00

Just the lookup flags.  Die, bastard, die...

Signed-off-by: Al Viro

vfs: Fix /proc//fdinfo/ file handling

2012-06-04T18:00:45+00:00

Cyrill Gorcunov reports that I broke the fdinfo files with commit
30a08bf2d31d ("proc: move fd symlink i_mode calculations into
tid_fd_revalidate()"), and he's quite right.

The tid_fd_revalidate() function is not just used for the /fd
symlinks, it's also used for the /fdinfo/ files, and the
permission model for those are different.

So do the dynamic symlink permission handling just for symlinks, making
the fdinfo files once more appear as the proper regular files they are.

Of course, Al Viro argued (probably correctly) that we shouldn't do the
symlink permission games at all, and make the symlinks always just be
the normal 'lrwxrwxrwx'.  That would have avoided this issue too, but
since somebody noticed that the permissions had changed (which was the
reason for that original commit 30a08bf2d31d in the first place), people
do apparently use this feature.

[ Basically, you can use the symlink permission data as a cheap "fdinfo"
  replacement, since you see whether the file is open for reading and/or
  writing by just looking at st_mode of the symlink.  So the feature
  does make sense, even if the pain it has caused means we probably
  shouldn't have done it to begin with. ]

Reported-and-tested-by: Cyrill Gorcunov 
Signed-off-by: Linus Torvalds

fs, proc: introduce /proc//task//children entry

2012-06-01T00:49:32+00:00

When we do checkpoint of a task we need to know the list of children the
task, has but there is no easy and fast way to generate reverse
parent->children chain from arbitrary  (while a parent pid is
provided in "PPid" field of /proc//status).

So instead of walking over all pids in the system (creating one big
process tree in memory, just to figure out which children a task has) --
we add explicit /proc//task//children entry, because the kernel
already has this kind of information but it is not yet exported.

This is a first level children, not the whole process tree.

Signed-off-by: Cyrill Gorcunov 
Reviewed-by: Oleg Nesterov 
Reviewed-by: Kees Cook 
Cc: Pavel Emelyanov 
Cc: Serge Hallyn 
Cc: KAMEZAWA Hiroyuki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

proc: pass "fd" by value in /proc/*/{fd,fdinfo} code

2012-06-01T00:49:29+00:00

Pass "fd" directly, not via pointer -- one less memory read.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

proc: don't do dummy rcu_read_lock/rcu_read_unlock on error path

2012-06-01T00:49:29+00:00

rcu_read_lock()/rcu_read_unlock() is nop for TINY_RCU, but is not a nop
for, say, PREEMPT_RCU.

proc_fill_cache() is called without RCU lock, there is no need to
lock/unlock on error path, simply jump out of the loop.

Signed-off-by: Alexey Dobriyan 
Cc: "Paul E. McKenney" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds