[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180702145108.73189-1-jannh@google.com>
Date: Mon, 2 Jul 2018 16:51:08 +0200
From: Jann Horn <jannh@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, jannh@...gle.com
Cc: Rik van Riel <riel@...hat.com>, Michal Hocko <mhocko@...e.com>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Kees Cook <keescook@...omium.org>
Subject: [PATCH] fork: don't copy inconsistent signal handler state to child
Before this change, if a multithreaded process forks while one of its
threads is changing a signal handler using sigaction(), the memcpy() in
copy_sighand() can race with the struct assignment in do_sigaction().
It isn't clear whether this can cause corruption of the userspace signal
handler pointer, but it definitely can cause inconsistency between
different fields of struct sigaction.
Take the appropriate spinlock to avoid this.
I have tested that this patch prevents inconsistency between sa_sigaction
and sa_flags, which is possible before this patch.
Signed-off-by: Jann Horn <jannh@...gle.com>
---
I haven't added a CC stable line to this patch because I feel that it
doesn't quite meet the bar; if anyone disagrees, please say so.
kernel/fork.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/fork.c b/kernel/fork.c
index 9440d61b925c..4c86e8daae53 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1394,7 +1394,9 @@ static int copy_sighand(unsigned long clone_flags, struct task_struct *tsk)
return -ENOMEM;
atomic_set(&sig->count, 1);
+ spin_lock_irq(¤t->sighand->siglock);
memcpy(sig->action, current->sighand->action, sizeof(sig->action));
+ spin_unlock_irq(¤t->sighand->siglock);
return 0;
}
--
2.18.0.399.gad0ab374a1-goog
Powered by blists - more mailing lists