linux-kernel - [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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250917125733.2346923-1-xiujianfeng@huaweicloud.com>
Date: Wed, 17 Sep 2025 12:57:33 +0000
From: Xiu Jianfeng <xiujianfeng@...weicloud.com>
To: rostedt@...dmis.org,
	mhiramat@...nel.org,
	mathieu.desnoyers@...icios.com,
	gmonaco@...hat.com,
	namcao@...utronix.de
Cc: linux-trace-kernel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	nicolas.bouchinet@....cyber.gouv.fr,
	xiujianfeng@...wei.com
Subject: [PATCH] rv: Fix boot failure when kernel lockdown is active

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,

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)
-- 
2.43.0