From: Rand Deeb <rand.sec96@gmail.com>
To: Dave Kleikamp <shaggy@kernel.org>,
jfs-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Cc: deeb.rand@confident.ru, lvc-project@linuxtesting.org,
voskresenski.stanislav@confident.ru,
Rand Deeb <rand.sec96@gmail.com>
Subject: [PATCH] fs/jfs: prevent potential integer overflow in dbMapFileSizeToMapSize
Date: Tue, 25 Feb 2025 14:41:10 +0300 [thread overview]
Message-ID: <20250225114110.1775745-1-rand.sec96@gmail.com> (raw)
In dbMapFileSizeToMapSize(), the calculation involving 'complete' and
'LPERCTL' can result in a 32-bit integer overflow when handling large
filesystems. Specifically, multiplying 'complete' by LPERCTL * LPERCTL
(1,048,576) can exceed the 32-bit integer limit if 'complete' is greater
than approximately 2,047.
While there is no evidence that 'complete' can exceed this threshold,
theoretically, this is possible. To ensure robustness and maintainability,
this patch casts only 'complete' to s64 (64-bit integer) before performing
the multiplication. This guarantees that the arithmetic is conducted in
64-bit space, accommodating larger values without overflow.
This change enhances the reliability of the JFS filesystem when managing
large volumes and preemptively addresses potential overflow issues.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Rand Deeb <rand.sec96@gmail.com>
---
fs/jfs/jfs_dmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/jfs/jfs_dmap.c b/fs/jfs/jfs_dmap.c
index edb22cf9521a..380e73c516ee 100644
--- a/fs/jfs/jfs_dmap.c
+++ b/fs/jfs/jfs_dmap.c
@@ -4059,7 +4059,7 @@ s64 dbMapFileSizeToMapSize(struct inode * ipbmap)
factor =
(i == 2) ? MAXL1PAGES : ((i == 1) ? MAXL0PAGES : 1);
complete = (u32) npages / factor;
- ndmaps += complete * ((i == 2) ? LPERCTL * LPERCTL :
+ ndmaps += (s64)complete * ((i == 2) ? LPERCTL * LPERCTL :
((i == 1) ? LPERCTL : 1));
/* pages in last/incomplete child */
--
2.34.1
next reply other threads:[~2025-02-25 11:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-25 11:41 Rand Deeb [this message]
2025-02-25 19:52 ` [PATCH] fs/jfs: prevent potential integer overflow in dbMapFileSizeToMapSize Fedor Pchelkin
2025-03-11 16:21 ` Dave Kleikamp
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=20250225114110.1775745-1-rand.sec96@gmail.com \
--to=rand.sec96@gmail.com \
--cc=deeb.rand@confident.ru \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=shaggy@kernel.org \
--cc=voskresenski.stanislav@confident.ru \
/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