linux-kernel - Re: [PATCH 1/2] module: Override -EEXISTS module return

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: <geqat2upyxwvqjsp4ietmeypf4gmeoerg6akstbvelnxe3zpl4@dzqhyolsvtvc>
Date: Mon, 10 Nov 2025 09:31:58 -0600
From: Lucas De Marchi <lucas.demarchi@...el.com>
To: Daniel Gomez <da.gomez@...nel.org>
CC: <linux-modules@...r.kernel.org>, <linux-kernel@...r.kernel.org>, "Petr
 Pavlu" <petr.pavlu@...e.com>
Subject: Re: [PATCH 1/2] module: Override -EEXISTS module return

On Mon, Nov 10, 2025 at 04:17:47PM +0100, Daniel Gomez wrote:
>On 13/10/2025 18.26, Lucas De Marchi wrote:
>> The -EEXIST errno is reserved by the module loading functionality. When
>> userspace calls [f]init_module(), it expects a -EEXIST to mean that the
>> module is already loaded in the kernel. If module_init() returns it,
>> that is not true anymore.
>>
>> Add a warning and override the return code to workaround modules
>> currently returning the wrong code. It's expected that they eventually
>> migrate to a better suited error.
>
>I've been following the thread (and apologies for the delay) and reviewing the
>patches, and I do not believe we should push this workaround. While this "fixes"
>the bug reported, it also hides the real problem and drivers will continue
>misusing EEXIST at module initialization.
>
>>From the bug report thread, I agree with Christophe's suggestion that
>nf_conntrack_helpers_register() should return EBUSY instead of EEXIST. This
>would fix the root cause for this particular module and will allow others to
>change their module behavior, if we also follow up with proper documentation
>about EEXIST.

the fix will always be for the modules to stop returning EEXIST, no
discussion on that. This is the messenger, not the fix. Someone starts
seeing this warning and reports the bug. Then the developers can fix
it. It's much easier than dealing with the outcome of a module returning
EEXIST. Also note that we already have a similar reasoning about adding
a warning for module return codes in this same function.

Even if we had the means to check possible return codes from all
module inits, we'd still have external modules.

See patch 2: after some time we can simplify the warning and maybe even
remove it.

Lucas De Marchi