linux-kernel - Re: [PATCH 1/6] fill_tgid: fix task

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: <20061030203418.GA677@oleg>
Date:	Mon, 30 Oct 2006 23:34:18 +0300
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Balbir Singh <balbir@...ibm.com>
Cc:	Andrew Morton <akpm@...l.org>,
	Shailabh Nagar <nagar@...son.ibm.com>, Jay Lan <jlan@....com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] fill_tgid: fix task_struct leak and possible oops

On 10/30, Balbir Singh wrote:
>
> Oleg Nesterov wrote:
> 
> > 2. release_task(first) can happen after fill_tgid() drops tasklist_lock,
> >    it is unsafe to dereference first->signal.
> > 
> 
> But, we have a reference to first via get_task_struct(). release_task()
> would do just a put_task_struct(). Am I missing something?

No, release_task() will reap the task. tsk->usage protects only task_struct
itself (more precisely, it protects against __put_task_struct()). And please
note that release_task()->__exit_signal() sets tsk->signal = NULL.

QUESTION: taskstats_exit_alloc() does kfree(kmem_cache_alloc()), is it OK?
Yes, it works, but is it good? The comment says:

	* @objp: pointer returned by kmalloc.

Another question,

	do_exit()
		taskstats_exit_alloc()
		...
		taskstats_exit_send()
		taskstats_exit_free()

What is the point? Why can't we have taskstats_exit() which does alloc+send+free
itself? This looks like unnecessary complication to me.

>From taskstats_exit_alloc:

	/*
	 * This is the cpu on which the task is exiting currently and will
	 * be the one for which the exit event is sent, even if the cpu
	 * on which this function is running changes later.
	 */

Why do we record current cpu exactly here? This task probably changed its
CPU many times since it entered sys_exit(), so what is the problem if it
will change CPU again before taskstats_exit_send() ?

Oleg.

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