linux-kernel - Re: [PATCH] rv: Fix boot failure when kernel lockdown is active

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: <b2c19df4c5036e956e4e892ac983d5488a8b9614.camel@redhat.com>
Date: Wed, 17 Sep 2025 15:57:36 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Xiu Jianfeng <xiujianfeng@...weicloud.com>, rostedt@...dmis.org, 
	mhiramat@...nel.org, namcao@...utronix.de
Cc: linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	nicolas.bouchinet@....cyber.gouv.fr, xiujianfeng@...wei.com
Subject: Re: [PATCH] rv: Fix boot failure when kernel lockdown is active

On Wed, 2025-09-17 at 12:57 +0000, Xiu Jianfeng wrote:
> From: Xiu Jianfeng <xiujianfeng@...wei.com>
> 
> When booting kernel with lockdown=confidentiality parameter, the
> system
> will hang at rv_register_reactor() due to waiting for
> rv_interface_lock,
> as shown in the following log,
> 

Thanks for finding this, the problem was already fixed in [1], which is
on its way to getting merged.

[1] -
https://lore.kernel.org/all/20250903065112.1878330-1-zhen.ni@easystack.cn

> INFO: task swapper/0:1 blocked for more than 122 seconds.
>       Not tainted 6.17.0-rc6-next-20250915+ #29
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
> message.
> task:swapper/0       state:D stack:0     pid:1     tgid:1     ppid:0
> Call Trace:
>  <TASK>
>  __schedule+0x492/0x1600
>  schedule+0x27/0xf0
>  schedule_preempt_disabled+0x15/0x30
>  __mutex_lock.constprop.0+0x538/0x9e0
>  ? vprintk+0x18/0x50
>  ? _printk+0x5f/0x90
>  __mutex_lock_slowpath+0x13/0x20
>  mutex_lock+0x3b/0x50
>  rv_register_reactor+0x48/0xe0
>  ? __pfx_register_react_printk+0x10/0x10
>  register_react_printk+0x15/0x20
>  do_one_initcall+0x5d/0x340
>  kernel_init_freeable+0x351/0x540
>  ? __pfx_kernel_init+0x10/0x10
>  kernel_init+0x1b/0x200
>  ? __pfx_kernel_init+0x10/0x10
>  ret_from_fork+0x1fb/0x220
>  ? __pfx_kernel_init+0x10/0x10
>  ret_from_fork_asm+0x1a/0x30
> 
> The root cause is that, when the kernel lockdown is in
> confidentiality
> mode, rv_create_dir(), which is essentially tracefs_create_dir(),
> will
> return NULL. This, in turn, causes create_monitor_dir() to return
> -ENOMEM, and finally leading to the mutex not being unlocked.
> 
> Fixes: 24cbfe18d55a ("rv: Merge struct rv_monitor_def into struct
> rv_monitor")
> Signed-off-by: Xiu Jianfeng <xiujianfeng@...wei.com>
> ---
>  kernel/trace/rv/rv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/trace/rv/rv.c b/kernel/trace/rv/rv.c
> index 1482e91c39f4..e35565dd2dc5 100644
> --- a/kernel/trace/rv/rv.c
> +++ b/kernel/trace/rv/rv.c
> @@ -805,7 +805,7 @@ int rv_register_monitor(struct rv_monitor
> *monitor, struct rv_monitor *parent)
>  
>  	retval = create_monitor_dir(monitor, parent);
>  	if (retval)
> -		return retval;
> +		goto out_unlock;
>  
>  	/* keep children close to the parent for easier
> visualisation */
>  	if (parent)