linux-kernel - Re: [PATCH v3 1/2] kernel/sys: add PR_GET_TASK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 May 2019 19:15:58 -0400
From:   Jann Horn <jannh@...gle.com>
To:     Joel Savitz <jsavitz@...hat.com>
Cc:     kernel list <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
        Kristina Martsenko <kristina.martsenko@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Cyrill Gorcunov <gorcunov@...il.com>,
        Kees Cook <keescook@...omium.org>,
        "Gustavo A. R. Silva" <gustavo@...eddedor.com>,
        YueHaibing <yuehaibing@...wei.com>,
        Micah Morton <mortonm@...omium.org>,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Rafael Aquini <aquini@...hat.com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Yury Norov <yury.norov@...il.com>,
        David Laight <David.Laight@...lab.com>
Subject: Re: [PATCH v3 1/2] kernel/sys: add PR_GET_TASK_SIZE option to prctl(2)

On Fri, May 3, 2019 at 2:12 PM Joel Savitz <jsavitz@...hat.com> wrote:
> When PR_GET_TASK_SIZE is passed to prctl, the kernel will attempt to
> copy the value of TASK_SIZE to the userspace address in arg2.

A commit message shouldn't just describe what you're doing, but also
why you're doing it. Is this intended for processes that are running
on X86-64 and want to determine whether the system supports 5-level
paging, or something like that?

> +static int prctl_get_tasksize(void __user *uaddr)
> +{
> +       unsigned long current_task_size, current_word_size;
> +
> +       current_task_size = TASK_SIZE;
> +       current_word_size = sizeof(unsigned long);
> +
> +#ifdef CONFIG_64BIT
> +       /* On 64-bit architecture, we must check whether the current thread
> +        * is running in 32-bit compat mode. If it is, we can simply cut
> +        * the size in half. This avoids corruption of the userspace stack.
> +        */
> +       if (test_thread_flag(TIF_ADDR32))
> +               current_word_size >>= 1;
> +#endif
> +
> +       return copy_to_user(uaddr, &current_task_size, current_word_size) ? -EFAULT : 0;
> +}

This function looks completely wrong; in particular, you're assuming
that the architecture is little-endian.
Make the value a u64, and you won't have these problems:

static int prctl_get_tasksize(u64 __user *uaddr)
{
        return put_user(TASK_SIZE, uaddr) ? -EFAULT : 0;
}

A bunch of other new pieces of userspace API already use "u64" to
store userspace pointers and lengths to avoid compat issues.

> @@ -2486,6 +2506,9 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
>                         return -EINVAL;
>                 error = PAC_RESET_KEYS(me, arg2);
>                 break;
> +       case PR_GET_TASK_SIZE:
> +               error = prctl_get_tasksize((void *)arg2);

s/void */void __user */