Commit 87ca4f9
sched/core: Fix use-after-free bug in dup_user_cpus_ptr()
Since commit 07ec77a ("sched: Allow task CPU affinity to be
restricted on asymmetric systems"), the setting and clearing of
user_cpus_ptr are done under pi_lock for arm64 architecture. However,
dup_user_cpus_ptr() accesses user_cpus_ptr without any lock
protection. Since sched_setaffinity() can be invoked from another
process, the process being modified may be undergoing fork() at
the same time. When racing with the clearing of user_cpus_ptr in
__set_cpus_allowed_ptr_locked(), it can lead to user-after-free and
possibly double-free in arm64 kernel.
Commit 8f9ea86 ("sched: Always preserve the user requested
cpumask") fixes this problem as user_cpus_ptr, once set, will never
be cleared in a task's lifetime. However, this bug was re-introduced
in commit 851a723 ("sched: Always clear user_cpus_ptr in
do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in
do_set_cpus_allowed(). This time, it will affect all arches.
Fix this bug by always clearing the user_cpus_ptr of the newly
cloned/forked task before the copying process starts and check the
user_cpus_ptr state of the source task under pi_lock.
Note to stable, this patch won't be applicable to stable releases.
Just copy the new dup_user_cpus_ptr() function over.
Fixes: 07ec77a ("sched: Allow task CPU affinity to be restricted on asymmetric systems")
Fixes: 851a723 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()")
Reported-by: David Wang 王标 <[email protected]>
Signed-off-by: Waiman Long <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Reviewed-by: Peter Zijlstra <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]1 parent 7fb3ff2 commit 87ca4f9
1 file changed
+29
-5
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
2612 | 2612 | | |
2613 | 2613 | | |
2614 | 2614 | | |
| 2615 | + | |
2615 | 2616 | | |
2616 | 2617 | | |
2617 | | - | |
| 2618 | + | |
| 2619 | + | |
| 2620 | + | |
| 2621 | + | |
| 2622 | + | |
| 2623 | + | |
| 2624 | + | |
| 2625 | + | |
| 2626 | + | |
| 2627 | + | |
| 2628 | + | |
| 2629 | + | |
2618 | 2630 | | |
2619 | 2631 | | |
2620 | | - | |
2621 | | - | |
| 2632 | + | |
| 2633 | + | |
2622 | 2634 | | |
2623 | 2635 | | |
2624 | | - | |
| 2636 | + | |
| 2637 | + | |
| 2638 | + | |
| 2639 | + | |
| 2640 | + | |
| 2641 | + | |
2625 | 2642 | | |
2626 | | - | |
| 2643 | + | |
| 2644 | + | |
| 2645 | + | |
| 2646 | + | |
2627 | 2647 | | |
| 2648 | + | |
| 2649 | + | |
| 2650 | + | |
| 2651 | + | |
2628 | 2652 | | |
2629 | 2653 | | |
2630 | 2654 | | |
| |||
0 commit comments