linux-kernel - Re: [PATCH RFC] pid: make setpgid() system call use RCU read-side critical section

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

Message-ID: <20100916163927.GA2873@redhat.com>
Date:	Thu, 16 Sep 2010 18:39:27 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Jiri Slaby <jslaby@...e.cz>
Cc:	paulmck@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	mingo@...e.hu, laijs@...fujitsu.com, dipankar@...ibm.com,
	akpm@...ux-foundation.org, mathieu.desnoyers@...ymtl.ca,
	josh@...htriplett.org, dvhltc@...ibm.com, niv@...ibm.com,
	tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
	Valdis.Kletnieks@...edu, dhowells@...hat.com,
	eric.dumazet@...il.com, jmorris@...ei.org, stable@...nel.org
Subject: Re: [PATCH RFC] pid: make setpgid() system call use RCU read-side
	critical section

On 09/16, Jiri Slaby wrote:
>
> On 09/10/2010 12:15 AM, Oleg Nesterov wrote:
> > On 08/30, Jiri Slaby wrote:
> >>> --- a/kernel/sys.c
> >>> +++ b/kernel/sys.c
> >>> @@ -938,6 +938,7 @@ SYSCALL_DEFINE2(setpgid, pid_t, pid, pid_t, pgid)
> >>>  	write_lock_irq(&tasklist_lock);
> >>>
> >>>  	err = -ESRCH;
> >>> +	rcu_read_lock();
> >>>  	p = find_task_by_vpid(pid);
> >>
> >> AFAICT the missing lock doesn't harm due to the write_lock of tasklist
> >> above. But is probably a good thing to do anyway.
> >
> > The problem is, find_task_by_vpid() is not safe without RCU. It is not
> > that the returned task_struct can't go away, find_pid_ns() itself is
> > not safe. This is because the failing copy_process() calls free_pid()
> > without tasklist_lock and modifies pid_hash[] list.
>
> That said, it (950eaaca681c4) should probably go into stable. (Apply to
> all 32-35 whichever are maintained currently.)

Perhaps, but the race is mostly theoretical.

To be honest, I think 950eaaca681c4 needs a comment to explain what
rcu_read_lock() protects, or perhaps we can make it more explicit.

Oleg.

--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -931,7 +931,6 @@ SYSCALL_DEFINE2(setpgid, pid_t, pid, pid
 		pgid = pid;
 	if (pgid < 0)
 		return -EINVAL;
-	rcu_read_lock();
 
 	/* From this point forward we keep holding onto the tasklist lock
 	 * so that our parent does not change from under us. -DaveM
@@ -939,7 +938,9 @@ SYSCALL_DEFINE2(setpgid, pid_t, pid, pid
 	write_lock_irq(&tasklist_lock);
 
 	err = -ESRCH;
+	rcu_read_lock();
 	p = find_task_by_vpid(pid);
+	rcu_read_unlock();
 	if (!p)
 		goto out;
 
@@ -968,7 +969,9 @@ SYSCALL_DEFINE2(setpgid, pid_t, pid, pid
 	if (pgid != pid) {
 		struct task_struct *g;
 
+		rcu_read_lock();
 		pgrp = find_vpid(pgid);
+		rcu_read_unlock();
 		g = pid_task(pgrp, PIDTYPE_PGID);
 		if (!g || task_session(g) != task_session(group_leader))
 			goto out;
@@ -985,7 +988,6 @@ SYSCALL_DEFINE2(setpgid, pid_t, pid, pid
 out:
 	/* All paths lead to here, thus we are safe. -DaveM */
 	write_unlock_irq(&tasklist_lock);
-	rcu_read_unlock();
 	return err;
 }
 

--
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/