All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dongliang Mu <dzm91@hust.edu.cn>
Cc: "Arve Hjønnevåg" <arve@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Martijn Coenen" <maco@android.com>,
	"Joel Fernandes" <joel@joelfernandes.org>,
	"Christian Brauner" <brauner@kernel.org>,
	"Carlos Llamas" <cmllamas@google.com>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Dongliang Mu" <mudongliangabcd@gmail.com>,
	syzkaller <syzkaller@googlegroups.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers: binderfs: fix memory leak in binderfs_fill_super
Date: Fri, 12 Aug 2022 15:41:46 +0200	[thread overview]
Message-ID: <YvZYmprZ1NiMkynp@kroah.com> (raw)
In-Reply-To: <20220812132124.2053673-1-dzm91@hust.edu.cn>

On Fri, Aug 12, 2022 at 09:21:24PM +0800, Dongliang Mu wrote:
> From: Dongliang Mu <mudongliangabcd@gmail.com>
> 
> In binderfs_fill_super, if s_root is not successfully initialized by
> d_make_root, the previous allocated s_sb_info will not be freed since
> generic_shutdown_super first checks if sb->s_root and then does
> put_super operation. The put_super operation calls binderfs_put_super
> to deallocate s_sb_info and put ipc_ns. This will lead to memory leak
> in binderfs_fill_super.
> 
> Fix this by invoking binderfs_put_super at error sites before s_root
> is successfully initialized.
> 
> Fixes: 095cf502b31e ("binderfs: port to new mount api")
> Reported-by: syzkaller <syzkaller@googlegroups.com>

Where is the specific syzkaller link for this report?  It would be good
to reference it so it can be properly checked.

Also, how did you test this change?

> Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
> ---
>  drivers/android/binderfs.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c
> index 588d753a7a19..20f5bc77495f 100644
> --- a/drivers/android/binderfs.c
> +++ b/drivers/android/binderfs.c
> @@ -710,8 +710,10 @@ static int binderfs_fill_super(struct super_block *sb, struct fs_context *fc)
>  	info->mount_opts.stats_mode = ctx->stats_mode;
>  
>  	inode = new_inode(sb);
> -	if (!inode)
> +	if (!inode) {
> +		binderfs_put_super(sb);
>  		return -ENOMEM;
> +	}
>  
>  	inode->i_ino = FIRST_INODE;
>  	inode->i_fop = &simple_dir_operations;
> @@ -721,8 +723,10 @@ static int binderfs_fill_super(struct super_block *sb, struct fs_context *fc)
>  	set_nlink(inode, 2);
>  
>  	sb->s_root = d_make_root(inode);
> -	if (!sb->s_root)
> +	if (!sb->s_root) {
> +		binderfs_put_super(sb);
>  		return -ENOMEM;
> +	}

How did you test this change to verify that you are not now just leaking
memory?  It looks to me like you just changed one problem for another
one :(

Please always be very very careful when making these types of changes,
and verify and test that they are correct.

thanks,

greg k-h

  parent reply	other threads:[~2022-08-12 13:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12 13:21 [PATCH] drivers: binderfs: fix memory leak in binderfs_fill_super Dongliang Mu
2022-08-12 13:41 ` Christian Brauner
2022-08-12 13:48   ` Dongliang Mu
2022-08-12 14:18     ` Christian Brauner
2022-08-15  0:59       ` Dongliang Mu
2022-08-12 13:41 ` Greg Kroah-Hartman [this message]
2022-08-12 13:56   ` Dongliang Mu
2022-08-12 14:02     ` Dongliang Mu
2022-08-12 14:09     ` Greg Kroah-Hartman
2022-08-12 14:24       ` Christian Brauner
2022-08-12 14:32         ` Greg Kroah-Hartman
2022-08-15  1:46           ` Al Viro
2022-08-15  1:48             ` Al Viro
2022-08-15  8:47             ` Christian Brauner
2022-08-17 11:43               ` Greg Kroah-Hartman
2022-08-17 13:03                 ` [PATCH] binderfs: rework superblock destruction Christian Brauner
2022-08-17 13:59                   ` Al Viro
2022-08-17 14:01                     ` Christian Brauner
2022-08-17 14:19                       ` Al Viro
2022-08-17 14:32                         ` Al Viro
2022-08-17 15:05                           ` Christian Brauner
2022-08-17 14:51                         ` Christian Brauner
2022-08-17 15:21                           ` Al Viro
2022-08-17 15:24                             ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YvZYmprZ1NiMkynp@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=arve@android.com \
    --cc=brauner@kernel.org \
    --cc=cmllamas@google.com \
    --cc=dzm91@hust.edu.cn \
    --cc=joel@joelfernandes.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maco@android.com \
    --cc=mudongliangabcd@gmail.com \
    --cc=surenb@google.com \
    --cc=syzkaller@googlegroups.com \
    --cc=tkjos@android.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.