linux-ext4 - [PATCH] libext2fs: Fix memory leak in the extents handling function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <1245052182-1892-1-git-send-email-tytso@mit.edu>
Date:	Mon, 15 Jun 2009 03:49:42 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Cc:	Theodore Ts'o <tytso@....edu>
Subject: [PATCH] libext2fs: Fix memory leak in the extents handling function

Each time an extent handle is opened and closed, if the inode has an
extent tree which does not fit in the inode's i_block structure, a
filesystem block buffer was not getting released.  Since e2fsck opens
an extent handle for every inode using extents, this can translate to
a very large amount of memory getting lost.

Thanks to Henrik 'Mauritz' Johnson for discovering and pointing out
this leak, which he ran into while running the "rdump" command in
debugfs.

Signed-off-by: "Theodore Ts'o" <tytso@....edu>
---
 lib/ext2fs/extent.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/ext2fs/extent.c b/lib/ext2fs/extent.c
index b7eb617..2b88739 100644
--- a/lib/ext2fs/extent.c
+++ b/lib/ext2fs/extent.c
@@ -168,7 +168,7 @@ extern void ext2fs_extent_free(ext2_extent_handle_t handle)
 	if (handle->inode)
 		ext2fs_free_mem(&handle->inode);
 	if (handle->path) {
-		for (i=1; i < handle->max_depth; i++) {
+		for (i=1; i <= handle->max_depth; i++) {
 			if (handle->path[i].buf)
 				ext2fs_free_mem(&handle->path[i].buf);
 		}
-- 
1.6.3.2.1.gb9f7d.dirty

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html