Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752591AbcKRH6z (ORCPT ); Fri, 18 Nov 2016 02:58:55 -0500 Received: from mail-ua0-f171.google.com ([209.85.217.171]:36447 "EHLO mail-ua0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751634AbcKRH6v (ORCPT ); Fri, 18 Nov 2016 02:58:51 -0500 MIME-Version: 1.0 From: Keno Fischer Date: Fri, 18 Nov 2016 02:58:08 -0500 Message-ID: Subject: Bug in fs/gs_base PTRACE_SETREGS on pre-4.7 kernels To: linux-kernel@vger.kernel.org Cc: luto@kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 824 Lines: 22 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