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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20210423014517.51196-1-lizhe67@huawei.com>
Date:   Fri, 23 Apr 2021 09:45:17 +0800
From:   Zhe Li <lizhe67@...wei.com>
To:     <nico@...xnic.net>, <viro@...iv.linux.org.uk>
CC:     <linux-kernel@...r.kernel.org>, <lizhe67@...wei.com>,
        <wangfangpeng1@...wei.com>, <zhongjubin@...wei.com>
Subject: Re:[PATCH] cramfs: fix potential "unable to mount root fs" problem

On Thu, 22 Apr 2021, Pitre wrote:
>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.

Hi Viro, please review my patch. Thank you.

>
>> ---
>>  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
>> 
>>