linux-kernel - Re: [RFC PATCH] workqueue: Fix rescuer task's name truncated

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]

Date: Sat, 11 May 2024 15:14:03 +0100
From: Aaron Tomlin <atomlin@...mlin.com>
To: Wenchao Hao <haowenchao22@...il.com>
Cc: Wenchao Hao <haowenchao2@...wei.com>, Tejun Heo <tj@...nel.org>, 
	Lai Jiangshan <jiangshanlai@...il.com>, linux-kernel@...r.kernel.org, neelx@...hat.com
Subject: Re: [RFC PATCH] workqueue: Fix rescuer task's name truncated

On Wed, Apr 24, 2024 at 11:12:24PM GMT, Wenchao Hao wrote:
> Hi Aaron, thanks a lot for your reply.

No problem.

> I think destroy_workqueue() may not race with wq_worker_comm(),
> wq_pool_attach_mutex is used to avoid race, below is my analysis.
> (Welcome to point out if my understand is incorrect)
> 
> t1 which call destroy_workqueue()     rescuer->task
> 
> destroy_workqueue()
>   kthread_stop(rescuer->task)
>                                       rescuer_thread()
> 	                                if (should_stop) {
> 	                                  __set_current_state(TASK_RUNNING);
> 	                                  set_pf_worker(false);
>                                             mutex_lock(&wq_pool_attach_mutex);
> 				            current->flags &= ~PF_WQ_WORKER;
> 				            mutex_unlock(&wq_pool_attach_mutex);
> 	                                  return 0;
> 	                                }
> 
>   kfree(rescuer)
> 
> wq_worker_comm() would acquire wq_pool_attach_mutex then check if task->flags
> is set PF_WQ_WORKER.
> If PF_WQ_WORKER is not set, wq_worker_comm() would not access this task's worker
> any more;
> If PF_WQ_WORKER is set, the wq_pool_attach_mutex is held durning access of task's
> worker.

Indeed. If I understand correctly then a use-after-free is theoretically
impossible due to the use of the 'wq_pool_attach_mutex' in the context of
rescuer_thread() and wq_pool_attach_mutex(), respectively.

> What confuse me mostly is why the origin logic only append worker's desc when
> worker is attached to a work pool.

I can only assume there was no intention to use the rescuer kworker's
description information for this purpose. Your patch looks fine to me now.




-- 
Aaron Tomlin