mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Daniel v. Kirschten" <danielkirschten@gmail.com>
To: mcgrof@kernel.org, linux-modules@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH 6.10.0-rc2] kernel/module: avoid panic on loading broken module
Date: Thu, 6 Jun 2024 15:31:49 +0200	[thread overview]
Message-ID: <230772fc-1076-4afb-8f7a-e7c402548c3b@gmail.com> (raw)

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.

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.

Signed-off-by: Daniel Kirschten <danielkirschten@gmail.com>
---
  kernel/module/main.c | 6 ++++++
  1 file changed, 6 insertions(+)

diff --git a/kernel/module/main.c b/kernel/module/main.c
index d18a94b973e1..abba097551a2 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -1886,6 +1886,12 @@ static int elf_validity_cache_copy(struct load_info *info, int flags)
                 goto no_exec;
         }
  
+       if (!(shdr->sh_flags & SHF_WRITE)) {
+               pr_err("module %s: .gnu.linkonce.this_module must be writable\n",
+                      info->name ?: "(missing .modinfo section or name field)");
+               goto no_exec;
+       }
+
         if (shdr->sh_size != sizeof(struct module)) {
                 pr_err("module %s: .gnu.linkonce.this_module section size must match the kernel's built struct module size at run time\n",
                        info->name ?: "(missing .modinfo section or name field)");
-- 
2.34.1

             reply	other threads:[~2024-06-06 13:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-06 13:31 Daniel v. Kirschten [this message]
2024-06-18 19:58 ` Luis Chamberlain
2024-06-21 14:05   ` Daniel von Kirschten
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=230772fc-1076-4afb-8f7a-e7c402548c3b@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

all inboxes | Powered by JetHome®