linux-kernel - Bug in fs/gs_base PTRACE_SETREGS on pre-4.7 kernels

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

Message-ID: <CABV8kRyLtDgGhqNNPCx06nAZ3iDHoew6GxYeVuVv2OKj=oWxng@mail.gmail.com>
Date:   Fri, 18 Nov 2016 02:58:08 -0500
From:   Keno Fischer <keno@...iacomputing.com>
To:     linux-kernel@...r.kernel.org
Cc:     luto@...nel.org
Subject: Bug in fs/gs_base PTRACE_SETREGS on pre-4.7 kernels

Hi Andy (&list),

this is more of a heads up than a bug report, since it turns out you
already fixed this in

731e33e: x86/arch_prctl/64: Remove FSBASE/GSBASE < 4G optimization

In any case, without that commit, trying to use PTRACE_SETREGS to set
either fs_base, or gs_base to 0 when it was previously <4G, but wasn't
0, fails to take effect in the tracee.

This is caused by the `if (child->thread.fs != value)`, in
`ptrace.c:putreg`, which skips the `do_arch_prctl` call. Of course the
problem here is that while the optimization is in place `fs` is set to
0, but does not actually hold the fs base, so the call is incorrectly
skipped.

In any case, figured you may be interested that the commit changes behavior
(for the better - not complaining ;), even if user code does not go
out of its way to confuse ptrace.

Keno