linux-kernel - Re: Oops: 0003 [#1] PREEMPT SMP NOPTI

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] [day] [month] [year] [list]

Message-ID: <CAHk-=wj2NoonnH=H3VpfqkPk7t-UyEG8ij5WG0sLOyDdy59dnQ@mail.gmail.com>
Date:   Fri, 16 Nov 2018 10:56:56 -0600
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     kyle.leet@...il.com
Cc:     Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: Re: Oops: 0003 [#1] PREEMPT SMP NOPTI

On Thu, Nov 15, 2018 at 8:29 PM Kyle Sanderson <kyle.leet@...il.com> wrote:
>
> 2008(!) dual-core Atom box.
> [1027541.963573] BUG: unable to handle kernel paging request at ffffffffb0428a44
> [1027541.963647] IP: format_decode+0x20/0x3d0

The code decodes to:

   0: 55                    push   %rbp
   1: 48 8d 2e              lea    (%rsi),%rbp
   4: 53                    push   %rbx
   5: 48 8d 1f              lea    (%rdi),%rbx
   8: 48 8d 64 24 f8        lea    -0x8(%rsp),%rsp
   d: 0f b6 06              movzbl (%rsi),%eax
  10: 48 89 3c 24          mov    %rdi,(%rsp)
  14: 3c 01                cmp    $0x1,%al
  16: 74 4c                je     0x64
  18: 3c 02                cmp    $0x2,%al
  1a: 0f 84 a2 01 00 00    je     0x1c2
  20:* c6 06 00              movb   $0x0,(%rsi) <-- trapping instruction
  23: 0f b6 07              movzbl (%rdi),%eax
  26: 84 c0                test   %al,%al
  28: 0f 84 db 02 00 00    je     0x309

and that trapping instruction is, as far as I can tell, this one:

        /* By default */
        spec->type = FORMAT_TYPE_NONE;

and the fault seems to be a protection fault due to a write to a
read-only area (and yes, we *have* read from that 'spec' pointer
before that write.

> [1027541.965114] RIP: 0010:format_decode+0x20/0x3d0
> [1027541.965463] Call Trace:
> [1027541.965501]  vsnprintf+0x56/0x4d0

This is all very odd, because that "spec" pointer points to an
automatic variable on the stack of the vsnprintf() function, but we
have:

    RSP: ffff9e8c02267ba0
    RSI: ffffffffb0428a44

so it looks like some completely crazy register state corruption.

Is this repeatable at all? Do you see other random faults?

               Linus