[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250225114110.1775745-1-rand.sec96@gmail.com>
Date: Tue, 25 Feb 2025 14:41:10 +0300
From: Rand Deeb <rand.sec96@...il.com>
To: Dave Kleikamp <shaggy@...nel.org>,
jfs-discussion@...ts.sourceforge.net,
linux-kernel@...r.kernel.org
Cc: deeb.rand@...fident.ru,
lvc-project@...uxtesting.org,
voskresenski.stanislav@...fident.ru,
Rand Deeb <rand.sec96@...il.com>
Subject: [PATCH] fs/jfs: prevent potential integer overflow in dbMapFileSizeToMapSize
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@...il.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
Powered by blists - more mailing lists