linux-kernel - Re: [RFC PATCH 2/4] uaccess: Add non-pagefault user-space read functions

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]

Message-Id: <20190226130720.189c882ce8355bb605d1ca9d@kernel.org>
Date:   Tue, 26 Feb 2019 13:07:20 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Changbin Du <changbin.du@...il.com>,
        Jann Horn <jannh@...gle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Nadav Amit <namit@...are.com>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC PATCH 2/4] uaccess: Add non-pagefault user-space read
 functions

Hi Kees,

On Mon, 25 Feb 2019 09:06:55 -0800
Kees Cook <keescook@...omium.org> wrote:

> On Mon, Feb 25, 2019 at 6:06 AM Masami Hiramatsu <mhiramat@...nel.org> wrote:
> > +static __always_inline long strncpy_from_unsafe_common(char *dst,
> > +                               const char __user *unsafe_addr, long count)
> > +{
> > +       const char __user *src = unsafe_addr;
> > +       int ret;
> > +
> > +       pagefault_disable();
> > +       do {
> > +               ret = __get_user(*dst++, src++);
> > +       } while (dst[-1] && ret == 0 && src - unsafe_addr < count);
> > +       dst[-1] = '\0';
> > +       pagefault_enable();
> > +
> > +       return ret ? -EFAULT : src - unsafe_addr;
> > +}
> 
> I'm all for always NUL-truncating, but this isn't "strncpy" (which has
> the buggy maybe-I-didn't-NUL-terminate behavior). Can we call this
> strscpy_...() instead?

Yes, it is easy to me to fit it to strscpy spec and caller side too.
But if we reuse strncpy_from_user() as Linus suggested, it may be better
keep it or write a wrapper, since this function spec is still a bit
different from strscpy (this doesn't return -E2BIG but returns the
copied length of the string with NULL terminal byte).

Thank you,

-- 
Masami Hiramatsu <mhiramat@...nel.org>