Re: mtd-utils: [BUG] fsck.ubifs backwards compatibility issue wipes ubi volume encryption information

[Zhihao Cheng <chengzhihao1@huawei.com>]

在 2026/8/27 0:44, Devin Armstrong 写道:
> Hi,
> 
> Description:
> fsck.ubifs v2.3.1 will always detect fatal corruptions in a mkfs.ubifs v2.1.1 encrypted ubi volume. When fsck.ubifs is run with the -y option, it deletes the volume's encryption information and leaves the volume damaged.
> 
> Steps to Reproduce:
> I have attached a bash script to this email that can reproduce this issue reliably. Essentially, it:
> 1. Builds mtd-utils v2.1.1 and v2.3.1
> 2. uses mtdram to emulate an mtd device and attaches an ubi volume to it
> 3. format and encrypt the ubi volume with mkfs.ubifs v2.1.1
> 4. Run fsck.ubifs v2.3.1 against the encrypted ubi volume
> The script also allows you to test an unencrypted ubi volume for comparison
> 
> To run the script:
> sudo ./fsck_ubifs_reproduce_bug.sh --encrypted /path/to/staging/dir --no-patch
> 
> fsck.ubifs will output something like this:
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Read superblock
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Read master & init lpt
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Replay journal
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Handle orphan nodes
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Traverse TNC and construct files
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Check and handle invalid files
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): problem: File has inconsistent type, ino 65, inode type file(xattr), dentry c has type dir(xattr)
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Remove dentry? y
> 

Hi Devin,
There was a wrong type assignment in old mkfs.ubifs. which introduced an 
inconsistent problem in ubifs image. The problem is fixed by [1]. Then, 
the fsck will detect the inconsistent problem from the ubifs image made 
by old mkfs.ubifs.

[1] 
https://git.infradead.org/?p=mtd-utils.git;a=commit;h=d17b14d953b2ab56c938d6c7829b70b91c736efe

> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): problem: File has no dentries, ino 65 type file(xattr)
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Delete it? y
> 
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): problem: Encrypted file has no encryption information, ino 1 type dir
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Delete it? y
> 
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Check and handle unreachable files
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Check and correct files
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): Check whether the TNC is empty
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): problem: TNC is empty
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): inconsistent problem must be fixed
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): ********** Filesystem was modified **********
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): ********** WARNING: Filesystem still has errors **********
> fsck.ubifs[21612] (/dev/ubi0_0,danger mode): FSCK failed, exit code 5
> 
> The steps to reproduce should be agnostic to the linux kernel version, however for reference I am running this on an Ubuntu 24.04 with linux kernel version 7.0.0-30-generic
> 
> I have done some digging and I believe this issue stems from the fsck.ubifs tool is doing a strict type check in the "file_is_valid" function of the extract_files.c source code file. A fix in v2.2.1 (git hash: d17b14d953b2ab56c938d6c7829b70b91c736efe) changed xent->type  from  "UBIFS_ITYPE_DIR"  to "UBIFS_ITYPE_REG". The fsck.ubifs tool does not account for this change.

I think fsck.ubifs should not skip this inconsistency issue for the sake 
of compatibility, in case this issue was not introduced by the old 
version of the mkfs.ubifs tool.
> 
> I have made and tested a patch which I have also attached to this email.
> 
> With the patch applied fsck.ubifs outputs:
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Read superblock
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Read master & init lpt
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Replay journal
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Handle orphan nodes
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Traverse TNC and construct files
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Check and handle invalid files
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Check and handle unreachable files
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Check and correct files
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Check whether the TNC is empty
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Check and correct the space statistics
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Check and correct the index size
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Check and create root dir
> fsck.ubifs[24723] (/dev/ubi0_0,danger mode): Final committing
> fsck.ubifs[24723] (-): FSCK success!
> 
> Best,
> Devin Armstrong
> 
> 
> Email: darmstrong@tantalus.com
> www.tantalus.com
> 
> CONFIDENTIALITY NOTICE.  This documentation, including any attachments, transmitted by electronic mail is intended for the use of the individual to whom or the entity to which it is addressed, and may contain information which is proprietary, confidential, privileged and/or protected from disclosure by applicable laws. Confidentiality and privilege are not lost by this documentation having been sent to the wrong electronic mail address. If you are not the intended recipient (or the person responsible for delivering thereto) please immediately notify the sender and destroy this documentation and all copies (in any form and media); and note that any distribution, reproduction or other use of this documentation is strictly prohibited and may violate public and intellectual property laws.  Thank you.
> 
> -
> CONFIDENTIALITY NOTICE. This documentation, including any attachments, transmitted by electronic mail is intended for the use of the individual to whom or the entity to which it is addressed, and may contain information which is proprietary, confidential, privileged and/or protected from disclosure by applicable laws. Confidentiality and privilege are not lost by this documentation having been sent to the wrong electronic mail address. If you are not the intended recipient (or the person responsible for delivering thereto) please immediately notify the sender and destroy this documentation and all copies (in any form and media); and note that any distribution, reproduction or other use of this documentation is strictly prohibited and may violate public and intellectual property laws. Thank you.
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/