linux-kernel - Re: rust: wrong SAFETY comments in group

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: <aTLp73haymcs1fkX@google.com>
Date: Fri, 5 Dec 2025 14:19:27 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Oleg Nesterov <oleg@...hat.com>, Christian Brauner <christian@...uner.io>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	"Björn Roy Baron" <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>, 
	Danilo Krummrich <dakr@...nel.org>, Panagiotis Foliadis <pfoliadis@...teo.net>, 
	Shankari Anand <shankari.ak0208@...il.com>, FUJITA Tomonori <fujita.tomonori@...il.com>, 
	Alexey Gladkov <legion@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: rust: wrong SAFETY comments in group_leader() and pid() + questions

Thanks a lot for your email!

+Christian Brauner

On Fri, Dec 05, 2025 at 03:08:23PM +0100, Oleg Nesterov wrote:
> From rust/kernel/task.rs:
> 
>     pub fn group_leader(&self) -> &Task {
>         // SAFETY: The group leader of a task never changes after initialization, so reading this
>         // field is not a data race.
>         let ptr = unsafe { *ptr::addr_of!((*self.as_ptr()).group_leader) };
> 
>         // SAFETY: The lifetime of the returned task reference is tied to the lifetime of `self`,
>         // and given that a task has a reference to its group leader, we know it must be valid for
>         // the lifetime of the returned task reference.
>         unsafe { &*ptr.cast() }
>     }
> 
>     /// Returns the PID of the given task.
>     pub fn pid(&self) -> Pid {
>         // SAFETY: The pid of a task never changes after initialization, so reading this field is
>         // not a data race.
>         unsafe { *ptr::addr_of!((*self.as_ptr()).pid) }
>     }
> 
> The comments look wrong. Unless same_thread_group(current, task) == T, task->group_leader
> and/or task->pid can change if a non-leader task's sub-thread execs. This also means that
> in general it is not safe to dereference group_leader, for example this C code is not safe:
> 
> 	rcu_read_lock();
> 	task = find_task_by_vpid(vpid);
> 	if (task)
> 		get_task_struct(task);
> 	rcu_read_unlock();
> 
> 	if (task)
> 		pid = task->group_leader->pid; // BUG! ->group_leader can be already freed
> 
> 
> Now the questions. Sorry! I don't know rust.
> 
> 1. Can I simply remove these misleading comments? Or SAFETY comment is mandatory?

If the safety comments are wrong, then the code is probably wrong too!

What is the correct way to read the pid or group_leader fields of a
struct task_struct?

> 2. I am working on the patch(es) which move ->group_leader from task_struct to
>    signal_struct, so the 1st change adds the new trivial helper in preparation:
> 
> 	struct task_struct *task_group_leader(struct task_struct *task)
> 	{
> 		return task->group_leader; // will be updated
> 	}
> 
>    Now, how can I change group_leader() to use it? I guess I need to add
> 
> 	struct task_struct *rust_helper_task_group_leader(struct task_struct *task)
> 	{
> 		return task_group_leader(task);
> 	}
> 
>    into rust/helpers/task.c, but will something like
> 
> 	pub fn group_leader(&self) -> &Task {
> 		unsafe { bindings::task_group_leader(self.as_ptr()) }
> 	}
> 
>     work? I'm afraid it won't ;)

That looks like it should work. The rust_helper_ function is only
required if task_group_leader is marked `static inline`. Otherwise
bindings:: will pick up the function straight from the C header. (As
long as the relevant header is included in bindings_helper.h)

That still does raise the question of how you correctly call this
function if the group leader could be freed at any time.

Alice