linux-kernel - Re: [PATCH] ext4: prevent module unload while filesystem is in use

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <g6cbleoltydfxhdcuttckw7ntiqvwilqnbxegvec7eqtnqauje@e3h36x2lsj45>
Date: Wed, 30 Jul 2025 11:55:41 +0200
From: Jan Kara <jack@...e.cz>
To: Kevin Paul Reddy Janagari <kevinpaul468@...il.com>
Cc: tytso@....edu, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ext4: prevent module unload while filesystem is in use

On Thu 24-07-25 21:00:44, Kevin Paul Reddy Janagari wrote:
> preventing attempt to unload the ext4 module while the fs is still actively
> mounted by adding a check before exit
> 
> The crash occurs because ext4_inode_cache still contain objects
> in use when kmem_cache_destroy is called
> 
> This is a log of the bug produced by crepro given by a local syzkaller
> 
> [  301.647795] BUG ext4_inode_cache (Tainted: G  R                ): Objects remaining on __kmem_cache_shutdown()
> [  301.652120] -----------------------------------------------------------
> [  301.652120] 
> [  301.653366] Object 0xffff88800ec88008 @offset=8
> [  301.653877] Allocated in ext4_alloc_inode+0x27/0x1a0 [ext4] age=46055 cpu=0 pid=616
> [  301.655766]  ext4_alloc_inode+0x27/0x1a0 [ext4]
> [  301.657063]  alloc_inode+0x2b/0x120
> [  301.657570]  iget_locked+0x1ae/0x3e0
> [  301.658137]  __ext4_iget+0x243/0x1af0 [ext4]
> [  301.659197]  ext4_lookup+0x1b5/0x3e0 [ext4]
> [  301.660784]  __lookup_slow+0xd1/0x1f0
> [  301.661575]  walk_component+0x1a7/0x250
> [  301.662411]  path_lookupat+0x9a/0x2f0
> [  301.663179]  filename_lookup+0x14e/0x2e0
> [  301.663947]  vfs_statx+0xb9/0x240
> [  301.664622]  __do_sys_newstat+0x62/0xd0
> [  301.665376]  do_syscall_64+0x80/0x2c0
> [  301.666091]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> Was not able to reproduce on my host system
> Tested in a Qemu instance
> 
> Signed-off-by: Kevin Paul Reddy Janagari <kevinpaul468@...il.com>

This is definitely wrong. VFS calls get_filesystem() (to acquire module
refcount) when mounting the filesystem (in sget_fc() or sget() depending on
whether the filesystem has been converted to the new mount API or not).
This prevents module removal so there must have been something else that
broke this protection mechanism in the syzbot reproducer you have and we
need to figure out what *that* was.

								Honza

> ---
>  fs/ext4/super.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index c7d39da7e733..c6c77369a252 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -7480,8 +7480,24 @@ static int __init ext4_init_fs(void)
>  	return err;
>  }
>  
> +static void ext4_busy_check(struct super_block *sb, void *data)
> +{
> +	int *is_busy = data;
> +	*is_busy = 1;
> +}
> +
>  static void __exit ext4_exit_fs(void)
>  {
> +
> +	int is_busy = 0;
> +
> +	iterate_supers_type(&ext4_fs_type, ext4_busy_check, &is_busy);
> +
> +	if (is_busy) {
> +		pr_warn("ext4: Cannot unload module, filesystem is still in use.\n");
> +		return;
> +	}
> +
>  	ext4_destroy_lazyinit_thread();
>  	unregister_as_ext2();
>  	unregister_as_ext3();
> -- 
> 2.39.5
> 
> 
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR