Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <1556907021-29730-1-git-send-email-jsavitz@redhat.com> <1556907021-29730-2-git-send-email-jsavitz@redhat.com>
In-Reply-To: <1556907021-29730-2-git-send-email-jsavitz@redhat.com>
From:   Jann Horn <jannh@google.com>
Date:   Fri, 3 May 2019 19:15:58 -0400
Message-ID: <CAG48ez2CCQ02KYcjZVZYtcVjKN4WH111rdKHPEcYziM9tzmyiA@mail.gmail.com>
Subject: Re: [PATCH v3 1/2] kernel/sys: add PR_GET_TASK_SIZE option to prctl(2)
To:     Joel Savitz <jsavitz@redhat.com>
Cc:     kernel list <linux-kernel@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@kernel.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Waiman Long <longman@redhat.com>,
        Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
        Kristina Martsenko <kristina.martsenko@arm.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Cyrill Gorcunov <gorcunov@gmail.com>,
        Kees Cook <keescook@chromium.org>,
        "Gustavo A. R. Silva" <gustavo@embeddedor.com>,
        YueHaibing <yuehaibing@huawei.com>,
        Micah Morton <mortonm@chromium.org>,
        Yang Shi <yang.shi@linux.alibaba.com>,
        Alexey Dobriyan <adobriyan@gmail.com>,
        Rafael Aquini <aquini@redhat.com>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        Yury Norov <yury.norov@gmail.com>,
        David Laight <David.Laight@aculab.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, May 3, 2019 at 2:12 PM Joel Savitz <jsavitz@redhat.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 */