linux-kernel - Re: Is it really correct to check for breakpoint in kernel space against ptracer's address space?

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <25b7bea4-e319-99b8-ac4b-019f5b2a1904@kernel.org>
Date:	Mon, 9 May 2016 20:33:19 -0700
From:	Andy Lutomirski <luto@...nel.org>
To:	Ruslan Kabatsayev <b7.10110111@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Is it really correct to check for breakpoint in kernel space
 against ptracer's address space?

On 05/09/2016 01:43 AM, Ruslan Kabatsayev wrote:
> Hello all.
>
> Currently a 32-bit ptracer can't set HW breakpoints in tracee over
> address space limitations of _tracer_. Even if the tracee is 64-bit,
> doing PTRACE_POKEUSER into u_debugreg[n] with value>=0xffffe000 leads
> to EINVAL (below is a test tracer program to reproduce this). At the
> same time, if tracer is 64-bit, then for both 32- and 64-bit tracees
> the PTRACE_POKEUSER call will succeed even if violates address space
> constraints for tracee.
>
> I've traced this to arch_check_bp_in_kernel_space() in
> arch/x86/kernel/hw_breakpoint.c, which checks the address against
> TASK_SIZE, which as I understood refers to the current task, i.e.
> caller of the syscall, instead of the tracee (at least tracing this in
> Bochs leads me to this conclusion).

Is there any reason at all for TASK_SIZE to be different from TASK_SIZE_MAX?

/me needs to audit this stuff.

--Andy