From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Purva Yeshi <purvayeshi550@gmail.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Sasha Levin <sashal@kernel.org>,
agk@redhat.com, snitzer@kernel.org, dm-devel@lists.linux.dev
Subject: [PATCH AUTOSEL 6.16-5.10] md: dm-zoned-target: Initialize return variable r to avoid uninitialized use
Date: Fri, 8 Aug 2025 11:30:42 -0400 [thread overview]
Message-ID: <20250808153054.1250675-2-sashal@kernel.org> (raw)
In-Reply-To: <20250808153054.1250675-1-sashal@kernel.org>
From: Purva Yeshi <purvayeshi550@gmail.com>
[ Upstream commit 487767bff572d46f7c37ad846c4078f6d6c9cc55 ]
Fix Smatch-detected error:
drivers/md/dm-zoned-target.c:1073 dmz_iterate_devices()
error: uninitialized symbol 'r'.
Smatch detects a possible use of the uninitialized variable 'r' in
dmz_iterate_devices() because if dmz->nr_ddevs is zero, the loop is
skipped and 'r' is returned without being set, leading to undefined
behavior.
Initialize 'r' to 0 before the loop. This ensures that if there are no
devices to iterate over, the function still returns a defined value.
Signed-off-by: Purva Yeshi <purvayeshi550@gmail.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.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. Here's my
extensive analysis:
## Analysis of the Bug
The commit fixes a genuine uninitialized variable bug in
`dmz_iterate_devices()` function in drivers/md/dm-zoned-target.c:1073.
The bug occurs when:
1. The variable `r` is declared but not initialized at line 1065
2. If `dmz->nr_ddevs` is 0, the for loop at line 1067 is never entered
3. The function returns `r` at line 1073, which contains garbage data
This is a clear programming error that can lead to undefined behavior.
The function could return any arbitrary value when there are no devices
to iterate over.
## Why This Should Be Backported
1. **Real Bug Fix**: This fixes an actual bug that can cause
unpredictable behavior. An uninitialized return value can lead to:
- Incorrect error handling by callers
- Potential system instability
- Unpredictable behavior in device mapper operations
2. **Small and Contained Fix**: The fix is minimal - just initializing
`r` to 0. This follows the pattern used in other similar
iterate_devices implementations like `dm-cache-target.c:3438` where
`int r = 0;` is properly initialized.
3. **No Side Effects**: The change has no architectural impact or side
effects. It simply ensures the function returns a defined value (0)
when there are no devices to iterate, which is the expected behavior.
4. **Affects Users**: While the condition (nr_ddevs == 0) might be rare,
it's still a possible configuration that could affect users of dm-
zoned devices. The undefined behavior could manifest in various ways
depending on what's in memory.
5. **Static Analysis Finding**: This was caught by Smatch static
analysis, indicating it's a real code quality issue that should be
fixed.
6. **Follows Stable Rules**: The fix is:
- Obviously correct
- Fixes a real bug (uninitialized variable use)
- Minimal risk of regression
- Small change (1 line)
- No new features or architectural changes
## Technical Context
Looking at the code structure, `nr_ddevs` is set from `argc` in line
858, which must be at least 1 based on the check at line 835. However,
there could be error paths or future code changes that might result in
this function being called with nr_ddevs == 0, making this defensive
programming important.
The fix aligns with how other device mapper targets handle their
iterate_devices functions, where the return value is properly
initialized before use.
drivers/md/dm-zoned-target.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-zoned-target.c b/drivers/md/dm-zoned-target.c
index 5da3db06da10..9da329078ea4 100644
--- a/drivers/md/dm-zoned-target.c
+++ b/drivers/md/dm-zoned-target.c
@@ -1062,7 +1062,7 @@ static int dmz_iterate_devices(struct dm_target *ti,
struct dmz_target *dmz = ti->private;
unsigned int zone_nr_sectors = dmz_zone_nr_sectors(dmz->metadata);
sector_t capacity;
- int i, r;
+ int i, r = 0;
for (i = 0; i < dmz->nr_ddevs; i++) {
capacity = dmz->dev[i].capacity & ~(zone_nr_sectors - 1);
--
2.39.5
next prev parent reply other threads:[~2025-08-08 15:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-08 15:30 [PATCH AUTOSEL 6.16-6.6] apparmor: shift ouid when mediating hard links in userns Sasha Levin
2025-08-08 15:30 ` Sasha Levin [this message]
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-5.4] i3c: don't fail if GETHDRCAP is unsupported Sasha Levin
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-5.10] dm-mpath: don't print the "loaded" message if registering fails Sasha Levin
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-5.10] rtc: ds1307: handle oscillator stop flag (OSF) for ds1341 Sasha Levin
2025-08-11 16:46 ` Meagan Lloyd
2025-08-16 13:07 ` Sasha Levin
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-5.4] i3c: add missing include to internal header Sasha Levin
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-6.1] i3c: master: Initialize ret in i3c_i2c_notifier_call() Sasha Levin
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-5.4] PCI: pnv_php: Work around switches with broken presence detection Sasha Levin
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-6.1] module: Prevent silent truncation of module name in delete_module(2) Sasha Levin
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-6.1] apparmor: use the condition in AA_BUG_FMT even with debug disabled Sasha Levin
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-6.6] powerpc/eeh: Make EEH driver device hotplug safe Sasha Levin
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-6.12] apparmor: fix x_table_lookup when stacking is not the first entry Sasha Levin
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-6.1] dm-table: fix checking for rq stackable devices Sasha Levin
2025-08-08 15:30 ` [PATCH AUTOSEL 6.16-5.10] PCI: pnv_php: Clean up allocated IRQs on unplug Sasha Levin
2025-08-08 15:59 ` Timothy Pearson
2025-08-08 17:04 ` 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=20250808153054.1250675-2-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=agk@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=mpatocka@redhat.com \
--cc=patches@lists.linux.dev \
--cc=purvayeshi550@gmail.com \
--cc=snitzer@kernel.org \
--cc=stable@vger.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