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

Date:   Fri, 14 Apr 2023 21:53:22 +0200
From:   Alejandro Colomar <alx.manpages@...il.com>
To:     Sergei Zhirikov <sfzhi@...oo.com>, Oleg Nesterov <oleg@...hat.com>
Cc:     linux-man@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Checking for support of ptrace(PTRACE_SEIZE,...) on older kernels

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


Download attachment "OpenPGP_signature" of type "application/pgp-signature" (834 bytes)