• Ingo Molnar's avatar
    fs/proc, core/debug: Don't expose absolute kernel addresses via wchan · b2f73922
    Ingo Molnar authored
    So the /proc/PID/stat 'wchan' field (the 30th field, which contains
    the absolute kernel address of the kernel function a task is blocked in)
    leaks absolute kernel addresses to unprivileged user-space:
    
            seq_put_decimal_ull(m, ' ', wchan);
    
    The absolute address might also leak via /proc/PID/wchan as well, if
    KALLSYMS is turned off or if the symbol lookup fails for some reason:
    
    static int proc_pid_wchan(struct seq_file *m, struct pid_namespace *ns,
                              struct pid *pid, struct task_struct *task)
    {
            unsigned long wchan;
            char symname[KSYM_NAME_LEN];
    
            wchan = get_wchan(task);
    
            if (lookup_symbol_name(wchan, symname) < 0) {
                    if (!ptrace_may_access(task, PTRACE_MODE_READ))
                            return 0;
                    seq_printf(m, "%lu", wchan);
            } else {
                    seq_printf(m, "%s", symname);
            }
    
            return 0;
    }
    
    This isn't ideal, because for example it trivially leaks the KASLR offset
    to any local attacker:
    
      fomalhaut:~> printf "%016lx\n" $(cat /proc/$$/stat | cut -d' ' -f35)
      ffffffff8123b380
    
    Most real-life uses of wchan are symbolic:
    
      ps -eo pid:10,tid:10,wchan:30,comm
    
    and procps uses /proc/PID/wchan, not the absolute address in /proc/PID/stat:
    
      triton:~/tip> strace -f ps -eo pid:10,tid:10,wchan:30,comm 2>&1 | grep wchan | tail -1
      open("/proc/30833/wchan", O_RDONLY)     = 6
    
    There's one compatibility quirk here: procps relies on whether the
    absolute value is non-zero - and we can provide that functionality
    by outputing "0" or "1" depending on whether the task is blocked
    (whether there's a wchan address).
    
    These days there appears to be very little legitimate reason
    user-space would be interested in  the absolute address. The
    absolute address is mostly historic: from the days when we
    didn't have kallsyms and user-space procps had to do the
    decoding itself via the System.map.
    
    So this patch sets all numeric output to "0" or "1" and keeps only
    symbolic output, in /proc/PID/wchan.
    
    ( The absolute sleep address can generally still be profiled via
      perf, by tasks with sufficient privileges. )
    Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Acked-by: default avatarKees Cook <keescook@chromium.org>
    Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    Cc: <stable@vger.kernel.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Alexander Potapenko <glider@google.com>
    Cc: Andrey Konovalov <andreyknvl@google.com>
    Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: Kostya Serebryany <kcc@google.com>
    Cc: Mike Galbraith <efault@gmx.de>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sasha Levin <sasha.levin@oracle.com>
    Cc: kasan-dev <kasan-dev@googlegroups.com>
    Cc: linux-kernel@vger.kernel.org
    Link: http://lkml.kernel.org/r/20150930135917.GA3285@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    b2f73922
proc.txt 84.9 KB