linux-kernel - Re: Checking for support of ptrace(PTRACE

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: <20230417115009.GA906@redhat.com>
Date:   Mon, 17 Apr 2023 13:50:10 +0200
From:   Oleg Nesterov <oleg@...hat.com>
To:     Alejandro Colomar <alx.manpages@...il.com>
Cc:     Sergei Zhirikov <sfzhi@...oo.com>, linux-man@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Checking for support of ptrace(PTRACE_SEIZE,...) on older kernels

Well, from https://man7.org/linux/man-pages/man2/ptrace.2.html

       ESRCH  The specified process does not exist, or is not currently
              being traced by the caller, or is not stopped (for
              requests that require a stopped tracee).

so if the kernel doesn't support PTRACE_SEIZE then ptrace(PTRACE_SEIZE)
should fail with -ESRCH as documented.

Perhaps this part

       EIO    request is invalid, or ...

can be improvef a bit to explain that this happens if the target is already
traced by us and stopped.

Oleg.

so in this case ptrace will fail with -ESRCH if called with an invalid request code

On 04/14, Alejandro Colomar wrote:
>
> Hi Sergei,
> 
> On 4/13/23 21:30, Sergei Zhirikov wrote:
> > Hello,
> > 
> > I've been studying the ptrace(2) man page and experimenting with ptrace() recently and came across this unexpected aspect of its behavior that I think would be good to have documented.
> > 
> > I would like to use PTRACE_SEIZE in my project because of the advantages it offers, but I would also like to support kernels older than 3.4 (where it was fully introduced). My thinking was that I would call ptrace(PTRACE_SEIZE, ...) and if it fails with the appropriate error code indicating that it's not supported I would fall back to PTRACE_ATTACH. That is where a little surprise was waiting for me. According to the man page, ptrace will fail with errno=EIO if called with an invalid request code. Logically, that was the error code I expected to get when PTRACE_SEIZE is not supported. In reality I got ESRCH instead. In my attempts to make sense of it I had to resort to reading the kernel source. Apparently, the logic in the kernel ( https://elixir.bootlin.com/linux/v3.0.101/source/kernel/ptrace.c#L944 ) seems to assume that any request other than PTRACE_ATTACH must come for an already existing tracee. So it proceeds to look for such a tracee (by calling ptrace_check_attach) before trying to interpret the request code. Obviously, in case of PTRACE_SEIZE, the target process/thread is not being traced yet, so ESRCH is returned. As far as I can tell by looking at the source code, that will happen for any request code (with a couple of exceptions), valid or otherwise. The relevant piece of logic seems to remain unchanged to this day, so this isn't just a problem with an ancient kernel that nobody cares about. I am not sure whether this behavior is intentional (I would guess it's not), but in any case it's probably good to have it documented in the man page.
> 
> I've added some CCs.  Feel free to send a patch.
> 
> Cheers,
> Alex
> 
> > 
> > Thanks and regards,
> > Sergei.
> 
> -- 
> <http://www.alejandro-colomar.es/>
> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5