linux-kernel - Re: [PATCH] cramfs: fix potential "unable to mount root fs" problem

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 for Android: free password hash cracker in your pocket

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

Message-ID: <p3554720-q5q8-nqo8-n01o-847oq81s6364@syhkavp.arg>
Date:   Thu, 22 Apr 2021 09:23:37 -0400 (EDT)
From:   Nicolas Pitre <nico@...xnic.net>
To:     lizhe <lizhe67@...wei.com>
cc:     linux-kernel@...r.kernel.org, wangfangpeng1@...wei.com,
        zhongjubin@...wei.com
Subject: Re: [PATCH] cramfs: fix potential "unable to mount root fs"
 problem

On Thu, 22 Apr 2021, lizhe wrote:

> We may encounter panic problem without "rootfstype=" options in
> bootargs. The logs are listed below.
> 
> [0.551962] RAMDISK: squashfs filesystem found at block 0
> [0.551977] RAMDISK: Loading 18117KiB [1 disk] into ram disk...
> [0.719465] done.
> [0.748379] VFS: Cannot open root device "ram0" or unknown-block(1,0): error -92
> [0.748390] Please append a correct "root=" boot option; here are the available partitions:
> [0.748408] 0100           65536 ram0
> [0.748413]  (driver?)
> [0.748430] 0101           65536 ram1
> [0.748434]  (driver?)
> [0.748450] 0102
> [0.748454]  (driver?)
> [0.748470] 0103           65536 ram3
> [0.748475]  (driver?)
> [0.748498] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
> [0.847579] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0 #68
> [0.847598] Call trace:
> [0.847616]  dump_backtrace+0x0/0x1f8
> [0.847627]  show_stack+0x30/0x40
> [0.847638]  dump_stack+0xdc/0x13c
> [0.847650]  panic+0x144/0x35c
> [0.847665]  mount_block_root+0x2c0/0x36c
> [0.847676]  mount_root+0x7c/0x90
> [0.847686]  prepare_namespace+0x178/0x188
> [0.847697]  kernel_init_freeable+0x220/0x28c
> [0.847708]  kernel_init+0x1c/0xf8
> [0.847719]  ret_from_fork+0x10/0x30
> 
> If we set CONFIG_CRAMFS_MTD and CONFIG_CRAMFS_BLOCKDEV to n,
> CONFIG_CRAMFS to y, function cramfs_get_tree return -ENOPROTOOPT,
> which breaks loops in function mount_block_root and we have no
> chance to try other filesystem type. In my opinion, ENOPROTOOPT
> is not an appropriate return value for cramfs mount function, so
> change it to EINVAL.
> 
> Fixes: 99c18ce58 (cramfs: direct memory access support)
> Signed-off-by: lizhe <lizhe67@...wei.com>

Acked-by: Nicolas Pitre <nico@...xnic.net>

Please send this to Al Viro for merging.


> ---
>  fs/cramfs/inode.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/cramfs/inode.c b/fs/cramfs/inode.c
> index 2be6526..9942955 100644
> --- a/fs/cramfs/inode.c
> +++ b/fs/cramfs/inode.c
> @@ -951,7 +951,7 @@ static const struct super_operations cramfs_ops = {
>  
>  static int cramfs_get_tree(struct fs_context *fc)
>  {
> -	int ret = -ENOPROTOOPT;
> +	int ret = -EINVAL;
>  
>  	if (IS_ENABLED(CONFIG_CRAMFS_MTD)) {
>  		ret = get_tree_mtd(fc, cramfs_mtd_fill_super);
> -- 
> 2.7.4
> 
>