From: Daniel von Kirschten <danielkirschten@gmail.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6.10.0-rc2] kernel/module: avoid panic on loading broken module
Date: Fri, 21 Jun 2024 16:05:27 +0200 [thread overview]
Message-ID: <82da9ad9-6a79-4edf-b38f-ef000b68c50a@gmail.com> (raw)
In-Reply-To: <ZnHm-5oljP8_5dFB@bombadil.infradead.org>
Am 18.06.2024 um 21:58 schrieb Luis Chamberlain:
> On Thu, Jun 06, 2024 at 03:31:49PM +0200, Daniel v. Kirschten wrote:
>> If a module is being loaded, and the .gnu.linkonce.this_module section
>> in the module's ELF file does not have the WRITE flag, the kernel will
>> map the finished module struct of that module as read-only.
>> This causes a kernel panic when the struct is written to the first time
>> after it has been marked read-only. Currently this happens in
>> complete_formation in kernel/module/main.c:2765 when the module's state is
>> set to MODULE_STATE_COMING, just after setting up the memory protections.
>
> How did you find this issue?
In a university course I got the assignment to manually craft a loadable
.ko file, given only a regular object file, without using Kbuild. During
testing my module files, most of them were simply (correctly) rejected
by the kernel with an appropriate error message, but at some point I ran
into this exact kernel panic, and investigated it to understand why my
module file was invalid.
>
>> Down the line, this seems to lead to unpredictable freezes when trying to
>> load other modules - I guess this is due to some structures not being
>> cleaned up properly, but I didn't investigate this further.
>>
>> A check already exists which verifies that .gnu.linkonce.this_module
>> is ALLOC. This patch simply adds an analogous check for WRITE.
>
> Can you check to ensure our modules generated have a respective check to
> ensure this check exists at build time? That would proactively inform
> userspace when a built module is not built correctly, and the tool
> responsible can be identified.
See above - I don't think it's possible to create such a broken module
file with any of "official" tools. I haven't looked too deeply into how
Kbuild actually builds modules, but as far as I know, the user doesn't
even come into contact with this_module when using the regular
toolchain, because Kbuild is responsible for creating the .this_module
section. And Kbuild of course creates it with the correct flags. So if I
understand correctly, this problem can only occur when the module was
built by some external tooling (or manually, in my case).
Daniel
next prev parent reply other threads:[~2024-06-21 14:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 13:31 [PATCH 6.10.0-rc2] kernel/module: avoid panic on loading broken module Daniel v. Kirschten
2024-06-18 19:58 ` Luis Chamberlain
2024-06-21 14:05 ` Daniel von Kirschten [this message]
2024-06-28 17:25 ` Luis Chamberlain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=82da9ad9-6a79-4edf-b38f-ef000b68c50a@gmail.com \
--to=danielkirschten@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox