[ 3.8.y.z extended stable ] Patch "ext4: fix memory leak in xattr" has been added to staging queue
Kamal Mostafa
kamal at canonical.com
Mon Oct 14 21:57:03 UTC 2013
This is a note to let you know that I have just added a patch titled
ext4: fix memory leak in xattr
to the linux-3.8.y-queue branch of the 3.8.y.z extended stable tree
which can be found at:
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.8.y-queue
This patch is scheduled to be released in version 3.8.13.12.
If you, or anyone else, feels it should not be added to this tree, please
reply to this email.
For more information about the 3.8.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable
Thanks.
-Kamal
------
>From d5d522595bf46102b2cee8d6adfa728bc4bf502e Mon Sep 17 00:00:00 2001
From: Dave Jones <davej at redhat.com>
Date: Thu, 10 Oct 2013 20:05:35 -0400
Subject: ext4: fix memory leak in xattr
commit 6e4ea8e33b2057b85d75175dd89b93f5e26de3bc upstream.
If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
potentionally return from the function without having freed these
allocations. If we don't do the return, we over-write the previous
allocation pointers, so we leak either way.
Spotted with Coverity.
[ Fixed by tytso to set is and bs to NULL after freeing these
pointers, in case in the retry loop we later end up triggering an
error causing a jump to cleanup, at which point we could have a double
free bug. -- Ted ]
Signed-off-by: Dave Jones <davej at fedoraproject.org>
Signed-off-by: "Theodore Ts'o" <tytso at mit.edu>
Reviewed-by: Eric Sandeen <sandeen at redhat.com>
Signed-off-by: Kamal Mostafa <kamal at canonical.com>
---
fs/ext4/xattr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index b93846b..f88c442 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1356,6 +1356,8 @@ retry:
s_min_extra_isize) {
tried_min_extra_isize++;
new_extra_isize = s_min_extra_isize;
+ kfree(is); is = NULL;
+ kfree(bs); bs = NULL;
goto retry;
}
error = -1;
--
1.8.1.2
More information about the kernel-team
mailing list