linux-kernel - Re: [PATCH v3 2/4] module: show why force load fails

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] [day] [month] [year] [list]

Message-ID: <c853de6a-ab46-4228-953f-f509e0c84b74@gmail.com>
Date: Tue, 2 Sep 2025 10:06:40 +0800
From: Jinchao Wang <wangjinchao600@...il.com>
To: Daniel Gomez <da.gomez@...nel.org>, Luis Chamberlain <mcgrof@...nel.org>,
 Petr Pavlu <petr.pavlu@...e.com>, Sami Tolvanen <samitolvanen@...gle.com>,
 linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 2/4] module: show why force load fails

On 9/2/25 02:29, Daniel Gomez wrote:
> On 29/08/2025 10.49, Jinchao Wang wrote:
>> Include reason in error message when force loading is disabled.
>>
>> Signed-off-by: Jinchao Wang<wangjinchao600@...il.com>
>> ---
>>   kernel/module/main.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/module/main.c b/kernel/module/main.c
>> index c66b26184936..e7484c6ce6e3 100644
>> --- a/kernel/module/main.c
>> +++ b/kernel/module/main.c
>> @@ -1083,6 +1083,7 @@ int try_to_force_load(struct module *mod, const char *reason)
>>   	add_taint_module(mod, TAINT_FORCED_MODULE, LOCKDEP_NOW_UNRELIABLE);
>>   	return 0;
>>   #else
>> +	pr_err("%s: %s, force load is not supported\n", mod->name, reason);
>>   	return -ENOEXEC;
>>   #endif
>>   }
> I don't think is good to inform via kernel log buffer what the kernel supports
> or what not. And definitely, not as an error.
> 

Thank you for the feedback.

When debugging syzkaller, I noticed that insmod only reports a generic
failure. To understand the exact reason, I needed to trace the kernel.
This patch was meant to make it more convenient to see the precise
cause directly.

In my view, if the caller cannot perform the requested operation, that
represents an error, and the kernel log buffer is the natural place to
report the reason. This makes debugging and testing easier without
requiring additional tracing.

-- 
Best regards,
Jinchao