linux-kernel - Re: Possible race in copy of fpu->state in copy

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:	Wed, 13 Apr 2016 12:25:56 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Jianyu Zhan <nasa4836@...il.com>
Cc:	Ingo Molnar <mingo@...nel.org>, mingo@...hat.com,
	"H. Peter Anvin" <hpa@...or.com>, suresh.b.siddha@...el.com,
	x86@...nel.org, LKML <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...nel.org>,
	Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dave Hansen <dave@...1.net>
Subject: Re: Possible race in copy of fpu->state in copy_process against
	the exeve'ing parent?

On 04/13, Jianyu Zhan wrote:
>
> From the panic stack trace, we can infer the call path before panic:
>
>
>         sys_clone
>           do_fork
>              copy_process
>                 dup_task_struct(current)
>                    prepare_to_copy(current)
>                       unlazy_fpu(current)
>                          __save_init_fpu(current)
>                            fpu_save_init(current)
>                              fpu_xsave(&current->thread.fpu) <---- PANIC
>
>
> In this case , &thread.fpu.state is NULL, so it caused a write to
> NULL address fault,

Yes, but iirc fpu.state == NULL is not a problem. The problem is that
TS_USEDFPU is set while it should not.

>       sys_execve
>          do_execve
>            do_execve_common
>              search_binary_handler
>                 load_elf_binary
>                   start_thread
>                     start_thread_common
>                        free_thread_xstate(current)
>                          fpu_free(&current->thread.fpu)
>                             fpu->state = NULL

Yes, but note that exec path also calls flush_thread() which clears TS_USEDFPU.

Yes, this is confusing, and we had a lot bugs in this area. To be honest I didn't
even try to recall how this (very old) code works, sorry... So I can't say what
exactly could explain the wrong TS_USEDFPU.

Oleg.