kernel/git/stable/linux.git/fs/proc/base.c, branch linux-2.6.29.y

proc: avoid information leaks to non-privileged processes

2009-05-08T22:45:09+00:00

commit f83ce3e6b02d5e48b3a43b001390e2b58820389d upstream. By using the same test as is used for /proc/pid/maps and /proc/pid/smaps, only allow processes that can ptrace() a given process to see information that might be used to bypass address space layout randomization (ASLR). These include eip, esp, wchan, and start_stack in /proc/pid/stat as well as the non-symbolic output from /proc/pid/wchan. ASLR can be bypassed by sampling eip as shown by the proof-of-concept code at http://code.google.com/p/fuzzyaslr/ As part of a presentation (http://www.cr0.org/paper/to-jt-linux-alsr-leak.pdf) esp and wchan were also noted as possibly usable information leaks as well. The start_stack address also leaks potentially useful information. Cc: Stable Team Signed-off-by: Jake Edge Acked-by: Arjan van de Ven Acked-by: "Eric W. Biederman" Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

fix setuid sometimes wouldn't

2009-05-08T22:45:06+00:00

commit 7c2c7d993044cddc5010f6f429b100c63bc7dffb upstream. check_unsafe_exec() also notes whether the fs_struct is being shared by more threads than will get killed by the exec, and if so sets LSM_UNSAFE_SHARE to make bprm_set_creds() careful about euid. But /proc//cwd and /proc//root lookups make transient use of get_fs_struct(), which also raises that sharing count. This might occasionally cause a setuid program not to change euid, in the same way as happened with files->count (check_unsafe_exec also looks at sighand->count, but /proc doesn't raise that one). We'd prefer exec not to unshare fs_struct: so fix this in procfs, replacing get_fs_struct() by get_fs_path(), which does path_get while still holding task_lock, instead of raising fs->count. Signed-off-by: Hugh Dickins Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman

Avoid 64-bit "switch()" statements on 32-bit architectures

2009-03-17T17:02:35+00:00

Commit ee6f779b9e0851e2f7da292a9f58e0095edf615a ("filp->f_pos not correctly updated in proc_task_readdir") changed the proc code to use filp->f_pos directly, rather than through a temporary variable. In the process, that caused the operations to be done on the full 64 bits, even though the offset is never that big. That's all fine and dandy per se, but for some unfathomable reason gcc generates absolutely horrid code when using 64-bit values in switch() statements. To the point of actually calling out to gcc helper functions like __cmpdi2 rather than just doing the trivial comparisons directly the way gcc does for normal compares. At which point we get link failures, because we really don't want to support that kind of crazy code. Fix this by just casting the f_pos value to "unsigned long", which is plenty big enough for /proc, and avoids the gcc code generation issue. Reported-by: Alexey Dobriyan Cc: Zhang Le Signed-off-by: Linus Torvalds

filp->f_pos not correctly updated in proc_task_readdir

2009-03-16T14:51:33+00:00

filp->f_pos only get updated at the end of the function. Thus d_off of those dirents who are in the middle will be 0, and this will cause a problem in glibc's readdir implementation, specifically endless loop. Because when overflow occurs, f_pos will be set to next dirent to read, however it will be 0, unless the next one is the last one. So it will start over again and again. There is a sample program in man 2 gendents. This is the output of the program running on a multithread program's task dir before this patch is applied: $ ./a.out /proc/3807/task --------------- nread=128 --------------- i-node# file type d_reclen d_off d_name 506442 directory 16 1 . 506441 directory 16 0 .. 506443 directory 16 0 3807 506444 directory 16 0 3809 506445 directory 16 0 3812 506446 directory 16 0 3861 506447 directory 16 0 3862 506448 directory 16 8 3863 This is the output after this patch is applied $ ./a.out /proc/3807/task --------------- nread=128 --------------- i-node# file type d_reclen d_off d_name 506442 directory 16 1 . 506441 directory 16 2 .. 506443 directory 16 3 3807 506444 directory 16 4 3809 506445 directory 16 5 3812 506446 directory 16 6 3861 506447 directory 16 7 3862 506448 directory 16 8 3863 Signed-off-by: Zhang Le Acked-by: Al Viro Signed-off-by: Linus Torvalds

Merge branch 'proc-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/adobriyan/proc

2009-01-07T20:01:06+00:00

* 'proc-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/adobriyan/proc: proc: remove write-only variable in proc_pident_lookup() proc: fix sparse warning proc: add /proc/*/stack proc: remove '##' usage proc: remove useless WARN_ONs proc: stop using BKL

zero i_uid/i_gid on inode allocation

2009-01-05T16:54:28+00:00

... and don't bother in callers. Don't bother with zeroing i_blocks, while we are at it - it's already been zeroed. i_mode is not worth the effort; it has no common default value. Signed-off-by: Al Viro

proc: remove write-only variable in proc_pident_lookup()

2009-01-05T09:27:45+00:00

Signed-off-by: WANG Cong Signed-off-by: Alexey Dobriyan

proc: fix sparse warning

2009-01-05T09:27:45+00:00

fs/proc/base.c:312:4: warning: do-while statement is not a compound statement Signed-off-by: Hannes Eder Signed-off-by: Alexey Dobriyan

proc: add /proc/*/stack

2009-01-05T09:27:44+00:00

/proc/*/stack adds the ability to query a task's stack trace. It is more useful than /proc/*/wchan as it provides full stack trace instead of single depth. Example output: $ cat /proc/self/stack [] save_stack_trace_tsk+0x17/0x35 [] proc_pid_stack+0x4a/0x76 [] proc_single_show+0x4a/0x5e [] seq_read+0xf3/0x29f [] vfs_read+0x6d/0x91 [] sys_read+0x3b/0x60 [] syscall_call+0x7/0xb [] 0xffffffff [add save_stack_trace_tsk() on mips, ACK Ralf --adobriyan] Signed-off-by: Ken Chen Signed-off-by: Ingo Molnar Signed-off-by: Alexey Dobriyan

proc: remove '##' usage

2009-01-05T09:27:44+00:00

Inability to jump to /proc/*/foo handlers with ctags is annoying. Signed-off-by: Alexey Dobriyan