From: Sami Tolvanen <samitolvanen@google.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: mcgrof@kernel.org, petr.pavlu@suse.com, da.gomez@kernel.org,
atomlin@atomlin.com, linux-modules@vger.kernel.org
Subject: Re: [PATCH v2] module: print version for external modules in print_modules()
Date: Thu, 5 Mar 2026 23:43:44 +0000 [thread overview]
Message-ID: <20260305234344.GA788042@google.com> (raw)
In-Reply-To: <20251231094004.37851-1-laoar.shao@gmail.com>
On Wed, Dec 31, 2025 at 05:40:04PM +0800, Yafang Shao wrote:
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3901,7 +3901,11 @@ void print_modules(void)
> list_for_each_entry_rcu(mod, &modules, list) {
> if (mod->state == MODULE_STATE_UNFORMED)
> continue;
> - pr_cont(" %s%s", mod->name, module_flags(mod, buf, true));
> + pr_cont(" %s", mod->name);
> + /* Only append version for out-of-tree modules */
> + if (mod->version && test_bit(TAINT_OOT_MODULE, &mod->taints))
> + pr_cont("-%s", mod->version);
> + pr_cont("%s", module_flags(mod, buf, true));
On second thought, is using mod->version here safe? We release the
memory for mod->version in:
free_module
-> mod_sysfs_teardown
-> module_remove_modinfo_attrs
-> attr->free = free_modinfo_version
And this happens before the module is removed from the
list. Couldn't there be a race condition where we read a non-NULL
mod->version here, but the buffer is being concurrently released
by another core that's unloading the module, resulting in a
use-after-free in the pr_cont call?
In order to do this safely, we should presumably drop the attr->free
call from module_remove_modinfo_attrs and release the attributes
only after the synchronize_rcu call in free_module (there's already
free_modinfo we can use), so mod->version is valid for the entire
time the module is on the list.
Thoughts?
Sami
next prev parent reply other threads:[~2026-03-05 23:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-31 9:40 [PATCH v2] module: print version for external modules in print_modules() Yafang Shao
2026-02-26 2:18 ` Yafang Shao
2026-02-26 18:39 ` Sami Tolvanen
2026-03-05 23:43 ` Sami Tolvanen [this message]
2026-03-06 8:53 ` Yafang Shao
2026-03-06 10:10 ` Petr Pavlu
2026-03-08 14:14 ` Yafang Shao
2026-03-09 14:02 ` Petr Pavlu
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=20260305234344.GA788042@google.com \
--to=samitolvanen@google.com \
--cc=atomlin@atomlin.com \
--cc=da.gomez@kernel.org \
--cc=laoar.shao@gmail.com \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=petr.pavlu@suse.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.