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
| ||
|
Date: Mon, 7 Nov 2022 19:06:40 +0800 From: Xiubo Li <xiubli@...hat.com> To: Luís Henriques <lhenriques@...e.de> Cc: Ilya Dryomov <idryomov@...il.com>, Jeff Layton <jlayton@...nel.org>, ceph-devel@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH] ceph: fix memory leak in mount error path when using test_dummy_encryption On 07/11/2022 18:23, Luís Henriques wrote: > On Mon, Nov 07, 2022 at 03:47:23PM +0800, Xiubo Li wrote: >> On 03/11/2022 23:36, Luís Henriques wrote: >>> Because ceph_init_fs_context() will never be invoced in case we get a >>> mount error, destroy_mount_options() won't be releasing fscrypt resources >>> with fscrypt_free_dummy_policy(). This will result in a memory leak. Add >>> an invocation to this function in the mount error path. >>> >>> Signed-off-by: Luís Henriques <lhenriques@...e.de> >>> --- >>> fs/ceph/super.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/fs/ceph/super.c b/fs/ceph/super.c >>> index 2224d44d21c0..6b9fd04b25cd 100644 >>> --- a/fs/ceph/super.c >>> +++ b/fs/ceph/super.c >>> @@ -1362,6 +1362,7 @@ static int ceph_get_tree(struct fs_context *fc) >>> ceph_mdsc_close_sessions(fsc->mdsc); >>> deactivate_locked_super(sb); >>> + fscrypt_free_dummy_policy(&fsc->fsc_dummy_enc_policy); >> Hi Luis, >> >> BTW, any reason the following code won't be triggered ? >> >> deactivate_locked_super(sb); >> >> --> fs->kill_sb(s); >> >> --> ceph_kill_sb() >> >> --> kill_anon_super() >> >> --> generic_shutdown_super() >> >> --> sop->put_super() >> >> --> ceph_put_super() >> >> --> ceph_fscrypt_free_dummy_policy() >> >> --> fscrypt_free_dummy_policy( >> > Here's what I'm seeing here: > > sys_mount->path_mount->do_new_mount->vfs_get_tree->ceph_get_tree > > ceph_get_tree() fails due to ceph_real_mount() returning an error. My > understanding is that that, since fc->root is never set, that code path > will never be triggered. Does that make sense? Okay, you are right! How about fixing it in ceph_real_mount() instead ? > > An easy way to reproduce is by running fstest ceph/005 with the > 'test_dummy_encryption' option. (I'll probably need to send a patch to > disable this test when this option is present.) Anyway this should be fixed in kceph. Thanks! - Xiubo > > Cheers, > -- > Luís >
Powered by blists - more mailing lists