From: Binbin Deng <18983559317@163.com>
To: mcgrof@kernel.org, petr.pavlu@suse.com, da.gomez@kernel.org,
samitolvanen@google.com, atomlin@atomlin.com
Cc: linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
Binbin Deng <18983559317@163.com>
Subject: [PATCH module v2] module: Fix uninitialized count read of unloaded taint tracking record
Date: Sat, 10 Oct 2026 16:03:56 +0800 [thread overview]
Message-ID: <20261010080356.6596-1-18983559317@163.com> (raw)
try_add_tainted_module() allocates the tracking record without zeroing
it and initializes the fields in this order:
mod_taint = kmalloc_obj(*mod_taint);
strscpy(mod_taint->name, mod->name, MODULE_NAME_LEN);
mod_taint->taints = mod->taints;
list_add_rcu(&mod_taint->list, &unloaded_tainted_modules);
mod_taint->count = 1;
The record is published by list_add_rcu() before the count field is
written. The readers, unloaded_tainted_modules_seq_show() (debugfs,
under rcu_read_lock()) and print_unloaded_tainted_modules() (panic
path, under guard(rcu)), traverse the list under RCU and read
mod_taint->count. module_mutex, which the writer holds, does not
exclude RCU readers.
A reader that observes the new node between the list_add_rcu() and
the count store reads an uninitialized u64 left over from previous
slab use. This is a data race and leaks kernel heap residue through
the debugfs file and the panic message.
The race window is two adjacent instructions; it is reachable when a
tainted module is unloaded (rmmod) concurrently with a read of
/sys/kernel/debug/module/unloaded_tainted, or with the module list
printout of an oops on another CPU.
Fix this by initializing count before the record is published.
Found during a static-analysis-assisted audit: candidate sites were
surfaced by a Coccinelle rule, and the reader/writer paths were
confirmed by LLM-assisted (GLM-5.3) code inspection. The issue was
not observed at runtime; it is identified by code inspection only.
Fixes: 99bd9956551b ("module: Introduce module unload taint tracking")
Signed-off-by: Binbin Deng <18983559317@163.com>
---
kernel/module/tracking.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/module/tracking.c b/kernel/module/tracking.c
index 9033ff54c4e2..9e8902600c32 100644
--- a/kernel/module/tracking.c
+++ b/kernel/module/tracking.c
@@ -38,8 +38,8 @@ int try_add_tainted_module(struct module *mod)
return -ENOMEM;
strscpy(mod_taint->name, mod->name, MODULE_NAME_LEN);
mod_taint->taints = mod->taints;
- list_add_rcu(&mod_taint->list, &unloaded_tainted_modules);
mod_taint->count = 1;
+ list_add_rcu(&mod_taint->list, &unloaded_tainted_modules);
out:
return 0;
}
--
2.43.0
reply other threads:[~2026-10-10 8:04 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261010080356.6596-1-18983559317@163.com \
--to=18983559317@163.com \
--cc=atomlin@atomlin.com \
--cc=da.gomez@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=samitolvanen@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox