linux-kernel - Re: [PATCH] kthread: potential dereference of null pointer

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: <YbHLVJ84QXxZdTqD@alley>
Date:   Thu, 9 Dec 2021 10:24:36 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Jiasheng Jiang <jiasheng@...as.ac.cn>
Cc:     akpm@...ux-foundation.org, valentin.schneider@....com,
        peterz@...radead.org, keescook@...omium.org,
        robdclark@...omium.org, samitolvanen@...gle.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kthread: potential dereference of null pointer

On Thu 2021-12-09 14:43:14, Jiasheng Jiang wrote:
> The return value of kzalloc() needs to be checked.
> To avoid use of null pointer in case of the failure of alloc.
> 
> Fixes: dc6a87f5450d ("sched: Make the idle task quack like a per-CPU
> kthread")

The hash id looks wrong:

$> git log -p -1 dc6a87f5450d
fatal: ambiguous argument 'dc6a87f5450d': unknown revision or path not in the working tree.


> Signed-off-by: Jiasheng Jiang <jiasheng@...as.ac.cn>
> ---
>  kernel/kthread.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index 08931e525dd9..3feefeff4922 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -101,6 +101,8 @@ void set_kthread_struct(struct task_struct *p)
>  		return;
>  
>  	kthread = kzalloc(sizeof(*kthread), GFP_KERNEL);
> +	if (!kthread)
> +		return;

This does not have any effect. It will only skip the assignment:

	p->set_child_tid = (__force void __user *)kthread;

But we are here only when p->set_child_tid is already NULL
because of the above check:

	if (__to_kthread(p))
		return;


>  	/*
>  	 * We abuse ->set_child_tid to avoid the new member and because it
>  	 * can't be wrongly copied by copy_process(). We also rely on fact

By other words. The change does not harm but it is not needed either.
Anyway, the commit message is misleading. It suggests that it fixes
something but it is not true.

I would personally keep the code as is. The original code makes it
more clear that the allocation failure is not handled.

Best Regards,
Petr