linux-kernel - Re: [PATCH v2] x86/dumpstack: Fix misleading instruction pointer error message

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: <CALCETrVoOA3u6Hej4r3n3d6C+ZE+wB0+mbOZzPUtLF6DzYZdCQ@mail.gmail.com>
Date:   Mon, 16 Nov 2020 19:29:11 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Borislav Petkov <bp@...en8.de>, Oleg Nesterov <oleg@...hat.com>,
        Mark Mossberg <mark.mossberg@...il.com>,
        Ingo Molnar <mingo@...hat.com>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Jann Horn <jannh@...gle.com>,
        kyin@...hat.com
Subject: Re: [PATCH v2] x86/dumpstack: Fix misleading instruction pointer
 error message

On Mon, Nov 16, 2020 at 3:37 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> On Mon, Nov 16 2020 at 15:04, Andy Lutomirski wrote:
>
> > On Mon, Nov 16, 2020 at 2:01 PM Thomas Gleixner <tglx@...utronix.de> wrote:
> >>  arch/x86/kernel/dumpstack.c |   23 +++++++++++++++++++----
> >>  1 file changed, 19 insertions(+), 4 deletions(-)
> >>
> >> --- a/arch/x86/kernel/dumpstack.c
> >> +++ b/arch/x86/kernel/dumpstack.c
> >> @@ -78,6 +78,9 @@ static int copy_code(struct pt_regs *reg
> >>         if (!user_mode(regs))
> >>                 return copy_from_kernel_nofault(buf, (u8 *)src, nbytes);
> >>
> >> +       /* The user space code from other tasks cannot be accessed. */
> >> +       if (regs != task_pt_regs(current))
> >> +               return -EPERM;
> >
> > Depending on exactly where this gets called, this may not be
> > sufficient.  You should also check nmi_uaccess_okay().
>
> which is what copy_from_user_nmi() already does.

Whoops.  I thought I checked that...