linux-kernel - Re: Trouble with ptrace self-attach rule since kernel

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: <200609010936.39015.ah2@delair.de>
Date:	Fri, 1 Sep 2006 09:36:38 +0200
From:	Andreas Hobein <ah2@...air.de>
To:	linux-kernel@...r.kernel.org
Cc:	Andrew Morton <akpm@...l.org>
Subject: Re: Trouble with ptrace self-attach rule since kernel > 2.6.14

On Friday 01 September 2006 03:39, Andrew Morton wrote:
> I'm unable to identify what patch you're referring to here.  Please be more
> specific so we can ask the person who developed it.

I assume the attached patch from Linus Torvalds causes my problem, since the 
condition was changed from "if (task == current)" to "if (task->tgid == 
current->tgid)" it breaks my application code. There may be other parts of 
the ptrace() kernel code that where changed accordingly that I'm not aware. 

There is also a reply from Roland McGrath (see 
http://lkml.org/lkml/2005/11/9/460) who mentioned that there may occur some 
problems in "some real programs out there". May be I'm the first one who is 
affected by this new behaviour.

To summarise my questions:
- Why should a thread not be allowed to ptrace_attach to a sibling thread
- while a forked child of this thread may do this ?
- Is there any other way to suspend sibling threads at arbitrary points like 
phread_suspend_np() does for example on AIX?

Thanks, Andreas

---------------------------
>From torvalds@...l.org Wed Nov  9 12:04:07 2005
Date: Wed, 9 Nov 2005 11:37:57 -0800 (PST)
From: Linus Torvalds <torvalds@...l.org>
Subject: Fix ptrace self-attach rule

Before we did CLONE_THREAD, the way to check whether we were attaching
to ourselves was to just check "current == task", but with CLONE_THREAD
we should check that the thread group ID matches instead.

Signed-off-by: Linus Torvalds <torvalds@...l.org>
---
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 5b8dd98..b88d418 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -155,7 +155,7 @@ int ptrace_attach(struct task_struct *ta
 	retval = -EPERM;
 	if (task->pid <= 1)
 		goto bad;
-	if (task == current)
+	if (task->tgid == current->tgid)
 		goto bad;
 	/* the same process cannot be attached many times */
 	if (task->ptrace & PT_PTRACED)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/