A memory-leak problem of unix_open()

Submitter	Theodore Ts'o
Date	Dec. 17, 2012, 1:20 a.m.
Message ID	<20121217012052.GA9130@thunk.org>
Download	mbox \| patch
Permalink	/patch/206764/
State	Accepted
Headers	show Return-Path: <linux-ext4-owner@vger.kernel.org> Date: Sun, 16 Dec 2012 20:20:52 -0500 From: Theodore Ts'o <tytso@mit.edu> To: Li Xi <pkuelelixi@gmail.com> Cc: linux-ext4@vger.kernel.org Subject: Re: A memory-leak problem of unix_open() Message-ID: <20121217012052.GA9130@thunk.org> References: <CAPTn0cDC2r3upOb=PAdT_SDH3HbYmkL-Me69RUMU2hxLZjBM7g@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAPTn0cDC2r3upOb=PAdT_SDH3HbYmkL-Me69RUMU2hxLZjBM7g@mail.gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk

Comments

Theodore Ts'o - Dec. 17, 2012, 1:20 a.m.

On Mon, Dec 17, 2012 at 12:34:56AM +0800, Li Xi wrote:
> I think I found a memory-leak problem of e2fsprofgs while using
> valgrind to testing a tool. 'log.txt' is the output. It is a simple
> problem. I wrote a patch, and it works on my server.

Thank you very much for reporting the problem!  While I was looking at
your patch, I found some some potential fd leaks that should also be
fixed.  This is what I have checked into the e2fsprogs tree.

Regards,

							- Ted

commit 4e0bb5eb745009decac4c5836671ff4bef21ce2a
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sun Dec 16 20:14:20 2012 -0500

    libext2fs: fix memory and fd leak in error path of unix_open()
    
    Fix a potential memory leak reported by Li Xi.  In addition, there
    were possible error cases where the file descriptor would not be
    properly closed, so fix those as well while we're at it.
    
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    Reported-by:  Li Xi <pkuelelixi@gmail.com>

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

Patch

diff --git a/lib/ext2fs/unix_io.c b/lib/ext2fs/unix_io.c
index 02570f0..7371654 100644
--- a/lib/ext2fs/unix_io.c
+++ b/lib/ext2fs/unix_io.c
@@ -505,6 +505,7 @@  static errcode_t unix_open(const char *name, int flags, io_channel *channel)
 	memset(data, 0, sizeof(struct unix_private_data));
 	data->magic = EXT2_ET_MAGIC_UNIX_IO_CHANNEL;
 	data->io_stats.num_fields = 2;
+	data->dev = -1;
 
 	open_flags = (flags & IO_FLAG_RW) ? O_RDWR : O_RDONLY;
 	if (flags & IO_FLAG_EXCLUSIVE)
@@ -575,7 +576,6 @@  static errcode_t unix_open(const char *name, int flags, io_channel *channel)
 		/* Is the block device actually writable? */
 		error = ioctl(data->dev, BLKROGET, &readonly);
 		if (!error && readonly) {
-			close(data->dev);
 			retval = EPERM;
 			goto cleanup;
 		}
@@ -621,11 +621,17 @@  static errcode_t unix_open(const char *name, int flags, io_channel *channel)
 
 cleanup:
 	if (data) {
+		if (data->dev >= 0)
+			close(data->dev);
 		free_cache(data);
 		ext2fs_free_mem(&data);
 	}
-	if (io)
+	if (io) {
+		if (io->name) {
+			ext2fs_free_mem(&io->name);
+		}
 		ext2fs_free_mem(&io);
+	}
 	return retval;
 }

Patchwork A memory-leak problem of unix_open()

Comments

Patch