From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Lifeng Zheng <zhenglifeng1@huawei.com>,
Chanwoo Choi <cw00.choi@samsung.com>,
Sasha Levin <sashal@kernel.org>,
myungjoo.ham@samsung.com, kyungmin.park@samsung.com,
linux-pm@vger.kernel.org
Subject: [PATCH AUTOSEL 6.15 26/80] PM / devfreq: governor: Replace sscanf() with kstrtoul() in set_freq_store()
Date: Sun, 3 Aug 2025 20:26:53 -0400 [thread overview]
Message-ID: <20250804002747.3617039-26-sashal@kernel.org> (raw)
In-Reply-To: <20250804002747.3617039-1-sashal@kernel.org>
From: Lifeng Zheng <zhenglifeng1@huawei.com>
[ Upstream commit 914cc799b28f17d369d5b4db3b941957d18157e8 ]
Replace sscanf() with kstrtoul() in set_freq_store() and check the result
to avoid invalid input.
Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
Link: https://lore.kernel.org/lkml/20250421030020.3108405-2-zhenglifeng1@huawei.com/
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Backport Status: YES
This commit should be backported to stable kernel trees for the
following reasons:
1. **Security Issue - Input Validation Bug**: The original code uses
`sscanf(buf, "%lu", &wanted)` at line 45 without checking the return
value. This is a security vulnerability because:
- `sscanf()` returns the number of successfully parsed items
- If the input is malformed or contains invalid characters,
`sscanf()` may return 0 but leave `wanted` uninitialized
- The code then proceeds to use this potentially uninitialized value
in `data->user_frequency = wanted`
- This could lead to setting arbitrary frequency values from
uninitialized stack data
2. **Real User Impact**: The devfreq userspace governor allows users to
manually set device frequencies through sysfs. Invalid input handling
could cause:
- Setting incorrect frequencies based on uninitialized memory
- Potential system instability if invalid frequencies are applied to
hardware
- Security implications as uninitialized stack data could be used
3. **Small and Contained Fix**: The change is minimal and low-risk:
- Replaces `sscanf()` with `kstrtoul()` which has proper error
checking
- Adds explicit error handling that returns early on invalid input
- The change is confined to a single function (`set_freq_store()`)
- No architectural changes or new features added
4. **Follows Kernel Best Practices**: The kernel has been systematically
replacing `sscanf()` with `kstrto*()` functions for better input
validation. This is evident from similar commits found in the git log
(e.g., commit a5556fa1107d for asus-wmi).
5. **Critical Subsystem**: While devfreq might not be as critical as
core memory management, it controls device frequency scaling which
can affect:
- Power management
- System performance
- Hardware stability
6. **No Negative Side Effects**: The change only adds proper validation
and doesn't modify the core functionality. Valid inputs will continue
to work exactly as before.
The commit fixes a clear bug (missing input validation) that could lead
to undefined behavior and potential security issues, making it an
excellent candidate for stable backporting according to stable tree
rules.
drivers/devfreq/governor_userspace.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/devfreq/governor_userspace.c b/drivers/devfreq/governor_userspace.c
index d1aa6806b683..175de0c0b50e 100644
--- a/drivers/devfreq/governor_userspace.c
+++ b/drivers/devfreq/governor_userspace.c
@@ -9,6 +9,7 @@
#include <linux/slab.h>
#include <linux/device.h>
#include <linux/devfreq.h>
+#include <linux/kstrtox.h>
#include <linux/pm.h>
#include <linux/mutex.h>
#include <linux/module.h>
@@ -39,10 +40,13 @@ static ssize_t set_freq_store(struct device *dev, struct device_attribute *attr,
unsigned long wanted;
int err = 0;
+ err = kstrtoul(buf, 0, &wanted);
+ if (err)
+ return err;
+
mutex_lock(&devfreq->lock);
data = devfreq->governor_data;
- sscanf(buf, "%lu", &wanted);
data->user_frequency = wanted;
data->valid = true;
err = update_devfreq(devfreq);
--
2.39.5
next prev parent reply other threads:[~2025-08-04 0:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250804002747.3617039-1-sashal@kernel.org>
2025-08-04 0:26 ` [PATCH AUTOSEL 6.15 04/80] cpufreq: CPPC: Mark driver with NEED_UPDATE_LIMITS flag Sasha Levin
2025-08-04 0:26 ` [PATCH AUTOSEL 6.15 23/80] cpufreq: Exit governor when failed to start old governor Sasha Levin
2025-08-04 0:26 ` [PATCH AUTOSEL 6.15 24/80] cpufreq: intel_pstate: Add Granite Rapids support in no-HWP mode Sasha Levin
2025-08-04 0:26 ` Sasha Levin [this message]
2025-08-04 0:26 ` [PATCH AUTOSEL 6.15 29/80] thermal/drivers/qcom-spmi-temp-alarm: Enable stage 2 shutdown when required Sasha Levin
2025-08-04 0:27 ` [PATCH AUTOSEL 6.15 42/80] PM: runtime: Clear power.needs_force_resume in pm_runtime_reinit() Sasha Levin
2025-08-04 0:27 ` [PATCH AUTOSEL 6.15 43/80] thermal: sysfs: Return ENODATA instead of EAGAIN for reads Sasha Levin
2025-08-04 0:27 ` [PATCH AUTOSEL 6.15 44/80] PM: sleep: console: Fix the black screen issue Sasha Levin
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=20250804002747.3617039-26-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=cw00.choi@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-pm@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=patches@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=zhenglifeng1@huawei.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;
as well as URLs for NNTP newsgroup(s).