Skip to contentSkip to conversation

isofs: avoid memory leak in iocharset

PATCH In review Hao Ge 3 participants 3 messages Nov 6, 2024

Subsystems (2)
VFS Isofs filesystem
lore
Share & tools
lore

Hao Ge

author
#0 lore raw

PATCH 1/1 isofs: avoid memory leak in iocharset

From: Hao Ge <[email protected]>

A memleak was found as below:

unreferenced object 0xffff0000d10164d8 (size 8):
comm "pool-udisksd", pid 108217, jiffies 4295408555 hex dump (first 8 bytes):

    75 74 66 38 00 cc cc cc                          utf8....
  backtrace (crc de430d31):
    [<ffff800081046e6c>] kmemleak_alloc+0xb8/0xc8
    [<ffff8000803e6c3c>] __kmalloc_node_track_caller_noprof+0x380/0x474
    [<ffff800080363b74>] kstrdup+0x70/0xfc
    [<ffff80007bb3c6a4>] isofs_parse_param+0x228/0x2c0 [isofs]
    [<ffff8000804d7f68>] vfs_parse_fs_param+0xf4/0x164
    [<ffff8000804d8064>] vfs_parse_fs_string+0x8c/0xd4
    [<ffff8000804d815c>] vfs_parse_monolithic_sep+0xb0/0xfc
    [<ffff8000804d81d8>] generic_parse_monolithic+0x30/0x3c
    [<ffff8000804d8bfc>] parse_monolithic_mount_data+0x40/0x4c
    [<ffff8000804b6a64>] path_mount+0x6c4/0x9ec
    [<ffff8000804b6e38>] do_mount+0xac/0xc4
    [<ffff8000804b7494>] __arm64_sys_mount+0x16c/0x2b0
    [<ffff80008002b8dc>] invoke_syscall+0x7c/0x104
    [<ffff80008002ba44>] el0_svc_common.constprop.1+0xe0/0x104
    [<ffff80008002ba94>] do_el0_svc+0x2c/0x38
    [<ffff800081041108>] el0_svc+0x3c/0x1b8

The opt->iocharset is freed inside the isofs_fill_super function, But there may be situations where it's not possible to enter this function.

For example, in the get_tree_bdev_flags function,when encountering the situation where "Can't mount, would change RO state," In such a case, isofs_fill_super will not have the opportunity to be called,which means that opt->iocharset will not have the chance to be freed,ultimately leading to a memory leak.

Let's move the memory freeing of opt->iocharset into isofs_free_fc function.

Fixes 1b17a46c9243 ("isofs: convert isofs to use the new mount API")
Signed-off-by Hao Ge <[email protected]>
---
 fs/isofs/inode.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
fs/isofs/inode.c +4 -4
index f50311a6b429..47038e660812 100644
@@ -948,8 +948,6 @@ static int isofs_fill_super(struct super_block *s, struct fs_context *fc)
 		goto out_no_inode;
 	}
 
-	kfree(opt->iocharset);
-
 	return 0;
 
 	/*

@@ -987,7 +985,6 @@ static int isofs_fill_super(struct super_block *s, struct fs_context *fc)
 	brelse(bh);
 	brelse(pri_bh);
 out_freesbi:
-	kfree(opt->iocharset);
 	kfree(sbi);
 	s->s_fs_info = NULL;
 	return error;

@@ -1528,7 +1525,10 @@ static int isofs_get_tree(struct fs_context *fc)
 
 static void isofs_free_fc(struct fs_context *fc)
 {
-	kfree(fc->fs_private);
+	struct isofs_options *opt = fc->fs_private;
+
+	kfree(opt->iocharset);
+	kfree(opt);
 }
 
 static const struct fs_context_operations isofs_context_ops = {
Signature · 1 line
2.25.1
maintainer
#1 lore raw
Quoted 36 lines · Hao Ge

From: Hao Ge <[email protected]>

A memleak was found as below:

unreferenced object 0xffff0000d10164d8 (size 8):
comm "pool-udisksd", pid 108217, jiffies 4295408555 hex dump (first 8 bytes):

    75 74 66 38 00 cc cc cc                          utf8....
  backtrace (crc de430d31):
    [<ffff800081046e6c>] kmemleak_alloc+0xb8/0xc8
    [<ffff8000803e6c3c>] __kmalloc_node_track_caller_noprof+0x380/0x474
    [<ffff800080363b74>] kstrdup+0x70/0xfc
    [<ffff80007bb3c6a4>] isofs_parse_param+0x228/0x2c0 [isofs]
    [<ffff8000804d7f68>] vfs_parse_fs_param+0xf4/0x164
    [<ffff8000804d8064>] vfs_parse_fs_string+0x8c/0xd4
    [<ffff8000804d815c>] vfs_parse_monolithic_sep+0xb0/0xfc
    [<ffff8000804d81d8>] generic_parse_monolithic+0x30/0x3c
    [<ffff8000804d8bfc>] parse_monolithic_mount_data+0x40/0x4c
    [<ffff8000804b6a64>] path_mount+0x6c4/0x9ec
    [<ffff8000804b6e38>] do_mount+0xac/0xc4
    [<ffff8000804b7494>] __arm64_sys_mount+0x16c/0x2b0
    [<ffff80008002b8dc>] invoke_syscall+0x7c/0x104
    [<ffff80008002ba44>] el0_svc_common.constprop.1+0xe0/0x104
    [<ffff80008002ba94>] do_el0_svc+0x2c/0x38
    [<ffff800081041108>] el0_svc+0x3c/0x1b8

The opt->iocharset is freed inside the isofs_fill_super function, But there may be situations where it's not possible to enter this function.

For example, in the get_tree_bdev_flags function,when encountering the situation where "Can't mount, would change RO state," In such a case, isofs_fill_super will not have the opportunity to be called,which means that opt->iocharset will not have the chance to be freed,ultimately leading to a memory leak.

Quoted 5 lines

Let's move the memory freeing of opt->iocharset into isofs_free_fc function.

Fixes 1b17a46c9243 ("isofs: convert isofs to use the new mount API")
Signed-off-by Hao Ge <[email protected]>

Thanks. I've added the patch to my tree.

Honza

Signature · 2 lines
Jan Kara <[email protected]>
SUSE Labs, CR
Reviewed-by on v1 1/1
#2 lore raw
In reply to Hao Ge
Quoted 1 line · Hao Ge

From: Hao Ge <[email protected]>

...

Quoted 10 lines

The opt->iocharset is freed inside the isofs_fill_super function, But there may be situations where it's not possible to enter this function.

For example, in the get_tree_bdev_flags function,when encountering the situation where "Can't mount, would change RO state," In such a case, isofs_fill_super will not have the opportunity to be called,which means that opt->iocharset will not have the chance to be freed,ultimately leading to a memory leak.

Quoted 5 lines

Let's move the memory freeing of opt->iocharset into isofs_free_fc function.

Fixes 1b17a46c9243 ("isofs: convert isofs to use the new mount API")
Signed-off-by Hao Ge <[email protected]>

Agreed, thank you.

Reviewed-by Eric Sandeen <[email protected]>