linux-kernel - Re: [4.14-rc7] task struct corruption after fork

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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 30 Oct 2017 11:59:30 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Dave Jones <davej@...emonkey.org.uk>,
        Andy Lutomirski <luto@...capital.net>,
        Ingo Molnar <mingo@...nel.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [4.14-rc7] task struct corruption after fork

On Mon, Oct 30, 2017 at 7:11 AM, Dave Jones <davej@...emonkey.org.uk> wrote:
> Something scary for halloween. Only saw this once so far.

Scary indeed.

I don't see any pattern. It's 18 quad-words with one unwritten entry
before the last one.

And most of them look like kernel pointers, but not all. The quad-words are:

    ffffffff81172d1e
    ffffffff8426daec
    ffffed008b17e001
    ffffffff811737e2
    ffffffff8426dbe0
    ffff880458bf0008
    ffffffff84590d00
    5
    ffffffff81172d00
    1
    1ffff1008b17dfed
    ffff880458bf00f0
    ffffed008b17dff9
    dffffc0000000000
    41b58ab3
    ffffffff82a349a8
    ffffffff81173540
    .. unwritten entry ..
    ffffffff8450f080

and it's at the end of the page, but not *quite* at the end of the page.

It smells almost like a "struct pt_regs *". The unwritten entry would
be "cs", and sp/ss would be missing, but the flags value isn't a sane
flags value either. Maybe I miscounted. Something like this:

    ffffffff81172d1e   r15
    ffffffff8426daec   r14
    ffffed008b17e001   r13
    ffffffff811737e2   r12
    ffffffff8426dbe0   rbp
    ffff880458bf0008   rbx
    ffffffff84590d00   r11
    5                  r10
    ffffffff81172d00   r9
    1                  r8
    1ffff1008b17dfed   rax
    ffff880458bf00f0   rcx
    ffffed008b17dff9   rdx
    dffffc0000000000   rsi
    41b58ab3           rdi
    ffffffff82a349a8   orig_eax
    ffffffff81173540   rip
    5a5a5a5a5a5a5a5a
    ffffffff8450f080   flags

and that location would *almost* make sense in that it's the end of
the same page that contained a "struct task_struct".

Are you running with VMAP_STACK? Is there perhaps some stale code that
ends up doing the old "stack pointer is in the same allocation as task
struct"?

Adding Andy and Ingo to the cc in case they see something.

If you have the kernel symbols for that image, can you look up if any
of those addresses look like any static kernel symbol addresses? Those
things that have the pattern  ffffffff8xxxxxxx might be symbol
addresses and give us a clue about where the values came from.

             Linus

> [10737.049397] =============================================================================
> [10737.052151] BUG task_struct (Not tainted): Padding overwritten. 0xffff880458befef8-0xffff880458beffcf
> [10737.055172] -----------------------------------------------------------------------------
> [10737.061267] Disabling lock debugging due to kernel taint
> [10737.064384] INFO: Slab 0xffffea001162fa00 objects=4 used=4 fp=0x          (null) flags=0x2ffc00000008100
> [10737.067771] CPU: 2 PID: 26357 Comm: trinity-c13 Tainted: G    B           4.14.0-rc7-think+ #1
> [10737.074807] Call Trace:
> [10737.089264]  slab_err+0xad/0xd0
> [10737.096769]  slab_pad_check.part.43+0xfa/0x160
> [10737.104600]  check_slab+0xa6/0xd0
> [10737.108563]  alloc_debug_processing+0x85/0x1b0
> [10737.112612]  ___slab_alloc+0x525/0x5d0
> [10737.137803]  __slab_alloc+0x3e/0x80
> [10737.142100]  kmem_cache_alloc_node+0xbd/0x360
> [10737.150932]  copy_process.part.42+0x101c/0x29e0
> [10737.352788]  _do_fork+0x1c4/0xa30
> [10737.468260]  do_syscall_64+0x182/0x400
> [10737.527991]  entry_SYSCALL64_slow_path+0x25/0x25
> [10737.600521] Padding ffff880458bef3d0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
> .... snip snip ...
> [10738.162127] Padding ffff880458befee0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
> [10738.163174] Padding ffff880458befef0: 5a 5a 5a 5a 5a 5a 5a 5a 1e 2d 17 81 ff ff ff ff  ZZZZZZZZ.-......
> [10738.164297] Padding ffff880458beff00: ec da 26 84 ff ff ff ff 01 e0 17 8b 00 ed ff ff  ..&.............
> [10738.165476] Padding ffff880458beff10: e2 37 17 81 ff ff ff ff e0 db 26 84 ff ff ff ff  .7........&.....
> [10738.166692] Padding ffff880458beff20: 08 00 bf 58 04 88 ff ff 00 0d 59 84 ff ff ff ff  ...X......Y.....
> [10738.167985] Padding ffff880458beff30: 05 00 00 00 00 00 00 00 00 2d 17 81 ff ff ff ff  .........-......
> [10738.169300] Padding ffff880458beff40: 01 00 00 00 00 00 00 00 ed df 17 8b 00 f1 ff 1f  ................
> [10738.170651] Padding ffff880458beff50: f0 00 bf 58 04 88 ff ff f9 df 17 8b 00 ed ff ff  ...X............
> [10738.172076] Padding ffff880458beff60: 00 00 00 00 00 fc ff df b3 8a b5 41 00 00 00 00  ...........A....
> [10738.173540] Padding ffff880458beff70: a8 49 a3 82 ff ff ff ff 40 35 17 81 ff ff ff ff  .I......@.......
> [10738.175095] Padding ffff880458beff80: 5a 5a 5a 5a 5a 5a 5a 5a 80 f0 50 84 ff ff ff ff  ZZZZZZZZ..P.....
> [10738.176722] Padding ffff880458beff90: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
> [10738.178385] Padding ffff880458beffa0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
> [10738.180082] Padding ffff880458beffb0: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ
> [10738.181758] Padding ffff880458beffc0: 5a 5a 5a 5a 5a 5a 5a 5a 80 0a 59 84 ff ff ff ff  ZZZZZZZZ..Y.....
> [10738.183501] FIX task_struct: Restoring 0xffff880458bef3d0-0xffff880458beffcf=0x5a