The index to access the threads ptrace_bps is controlled by userspace via syscall: sys_ptrace(), hence, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. The n can be controlled from: ptrace -> arch_ptrace -> ptrace_get_debugreg.
Fix this by sanitizing n before using it to index thread->ptrace_bps. Signed-off-by: Dianzhang Chen <dianzhangch...@gmail.com> --- arch/x86/kernel/ptrace.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c index a166c96..cbac646 100644 --- a/arch/x86/kernel/ptrace.c +++ b/arch/x86/kernel/ptrace.c @@ -25,6 +25,7 @@ #include <linux/rcupdate.h> #include <linux/export.h> #include <linux/context_tracking.h> +#include <linux/nospec.h> #include <linux/uaccess.h> #include <asm/pgtable.h> @@ -643,9 +644,11 @@ static unsigned long ptrace_get_debugreg(struct task_struct *tsk, int n) { struct thread_struct *thread = &tsk->thread; unsigned long val = 0; + int index = n; if (n < HBP_NUM) { - struct perf_event *bp = thread->ptrace_bps[n]; + index = array_index_nospec(index, HBP_NUM); + struct perf_event *bp = thread->ptrace_bps[index]; if (bp) val = bp->hw.info.address; -- 2.7.4