Jann Horn 16d51a590a sched/fair: Don't free p->numa_faults with concurrent readers
When going through execve(), zero out the NUMA fault statistics instead of
freeing them.

During execve, the task is reachable through procfs and the scheduler. A
concurrent /proc/*/sched reader can read data from a freed ->numa_faults
allocation (confirmed by KASAN) and write it back to userspace.
I believe that it would also be possible for a use-after-free read to occur
through a race between a NUMA fault and execve(): task_numa_fault() can
lead to task_numa_compare(), which invokes task_weight() on the currently
running task of a different CPU.

Another way to fix this would be to make ->numa_faults RCU-managed or add
extra locking, but it seems easier to wipe the NUMA fault statistics on
execve.

Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will@kernel.org>
Fixes: 82727018b0d3 ("sched/numa: Call task_numa_free() from do_execve()")
Link: https://lkml.kernel.org/r/20190716152047.14424-1-jannh@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-07-25 15:37:04 +02:00
..
2019-07-22 09:08:38 -07:00
2019-07-18 18:14:47 -05:00
2019-07-12 17:37:53 -07:00
2019-07-12 16:54:37 -07:00
2019-07-12 16:54:37 -07:00
2019-07-19 11:38:12 -07:00
2019-07-03 17:52:09 -04:00
2019-07-12 16:54:37 -07:00
2019-06-21 09:58:42 -07:00
\n
2019-07-10 20:27:07 -07:00
\n
2019-07-10 20:09:17 -07:00
\n
2019-07-10 20:27:07 -07:00
2019-07-18 11:18:00 -07:00
2019-07-15 21:20:52 -07:00
2019-05-21 08:23:41 +01:00
2019-07-19 11:38:12 -07:00
2019-04-08 18:21:02 -05:00
2019-03-08 14:48:40 -08:00
2019-07-12 16:54:37 -07:00
2019-07-10 21:22:43 -07:00
2019-02-07 16:38:35 +01:00
2019-07-04 22:01:58 -04:00