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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 30 Oct 2017 16:35:16 -0400
From:   Dave Jones <davej@...emonkey.org.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Andy Lutomirski <luto@...capital.net>,
        Ingo Molnar <mingo@...nel.org>,
        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 11:59:30AM -0700, Linus Torvalds wrote:

 > 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"?

yeah, it's enabled.

 > 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.

it got clobbered by another build, but I managed to rebuild it from the
older config. Modulo modules that were loaded, things should be the same.


>     ffffffff81172d1e   r15

ffffffff81172d00 t usage_match
ffffffff81172d30 t HARDIRQ_verbose

>     ffffffff8426daec   r14

ffffffff841cee60 b lock_classes
ffffffff844eed00 B nr_lock_classes

>     ffffed008b17e001   r13

>     ffffffff811737e2   r12

ffffffff81173540 t __bfs
ffffffff81173970 t check_noncircular

>     ffffffff8426dbe0   rbp

ffffffff841cee60 b lock_classes
ffffffff844eed00 B nr_lock_classes


>     ffff880458bf0008   rbx
>     ffffffff84590d00   r11

ffffffff841cee60 b lock_classes
ffffffff844eed00 B nr_lock_classes

>     5                  r10
>     ffffffff81172d00   r9

ffffffff81172d00 t usage_match

>     1                  r8
>     1ffff1008b17dfed   rax
>     ffff880458bf00f0   rcx
>     ffffed008b17dff9   rdx
>     dffffc0000000000   rsi
>     41b58ab3           rdi
>     ffffffff82a349a8   orig_eax

ffffffff828a7f40 R inat_primary_table
ffffffff82a42840 r POLY

>     ffffffff81173540   rip

ffffffff81173540 t __bfs

>     5a5a5a5a5a5a5a5a
>     ffffffff8450f080   flags

ffffffff844eed40 b list_entries
ffffffff846eed60 B nr_list_entries


So a bunch of lockdep stuff, and not much else afaics.

	Dave