[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Cluster-devel] [PATCH] fsck.gfs2: Allocate enough space for the block map



Building with gcc 4.8's address sanitizer and running the test suite
throws up an issue where the block map allocated in fsck.gfs2 is not
large enough when the required size is an odd number. For example, when
the number of blocks is 3, the mapsize (number of chars to allocate
memory for) would be (3 >> 1) which is too small as each block requires
4 bits. This patch adds 1 to the mapsize, as suggested in an existing
comment, to ensure we have enough space in these situations.

Note that this has (probably) never made fsck.gfs2 misbehave as it only
ever accessed 4 bits past the end of the block map and by chance that
memory was never being modified by anything else in the rare cases in
which it was used.

Resolves: bz#947384

Signed-off-by: Andrew Price <anprice redhat com>
---
 gfs2/fsck/util.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/gfs2/fsck/util.c b/gfs2/fsck/util.c
index 408d89a..3e3050f 100644
--- a/gfs2/fsck/util.c
+++ b/gfs2/fsck/util.c
@@ -534,15 +534,10 @@ static int gfs2_blockmap_create(struct gfs2_bmap *bmap, uint64_t size)
 
 	/* Have to add 1 to BLOCKMAP_SIZE since it's 0-based and mallocs
 	 * must be 1-based */
-	bmap->mapsize = BLOCKMAP_SIZE4(size);
+	bmap->mapsize = BLOCKMAP_SIZE4(size) + 1;
 
-	if (!(bmap->map = malloc(sizeof(char) * bmap->mapsize)))
+	if (!(bmap->map = calloc(bmap->mapsize, sizeof(char))))
 		return -ENOMEM;
-	if (!memset(bmap->map, 0, sizeof(char) * bmap->mapsize)) {
-		free(bmap->map);
-		bmap->map = NULL;
-		return -ENOMEM;
-	}
 	return 0;
 }
 
-- 
1.8.3.1


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]