Re: [PATCH] fs/jfs: fix potential integer overflow on shift of a int
From: Dave Kleikamp <hidden>
Date: 2021-02-09 16:54:05
Also in:
lkml
On 2/5/21 11:11 AM, Colin King wrote:
quoted hunk ↗ jump to hunk
From: Colin Ian King <redacted> The left shift of int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then assigned to a signed 64 bit integer. In the case where l2nb is 32 or more this can lead to an overflow. Avoid this by shifting using the BIT_ULL macro instead. Addresses-Coverity: ("Uninitentional integer overflow") Fixes: b40c2e665cd5 ("fs/jfs: TRIM support for JFS Filesystem") Signed-off-by: Colin Ian King <redacted> --- 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 94b7c1cb5ceb..47dbca7e52e0 100644 --- a/fs/jfs/jfs_dmap.c +++ b/fs/jfs/jfs_dmap.c@@ -1656,7 +1656,7 @@ s64 dbDiscardAG(struct inode *ip, int agno, s64 minlen) } else if (rc = -ENOSPC) { /* search for next smaller log2 block */ l2nb = BLKSTOL2(nblocks) - 1; - nblocks = 1 << l2nb; + nblocks = BIT_ULL(l2nb);
I'm not sure I like the use of this macro here. It seems to imply a bit flag of some sort. I think it would be clearer to use nblocks = 1ULL << l2nb; Maybe 1LL rather than 1ULL since nblocks is s64.
} else {
/* Trim any already allocated blocks */
jfs_error(bmp->db_ipbmap->i_sb, "-EIO\n");