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

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

[Devin Armstrong]

[-- Attachment #1: Type: text/plain, Size: 5800 bytes --]

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

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

[-- Attachment #2: fsck_ubifs_reproduce_bug.sh --]
[-- Type: application/x-shellscript, Size: 7442 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-fsck.ubifs-fix-for-pre-mkfs.ubifs-2.2.1-xattr-dentry-type.patch --]
[-- Type: text/x-patch; name="0001-fsck.ubifs-fix-for-pre-mkfs.ubifs-2.2.1-xattr-dentry-type.patch", Size: 778 bytes --]

diff --git a/ubifs-utils/fsck.ubifs/extract_files.c b/ubifs-utils/fsck.ubifs/extract_files.c
index 2e47b42..7aeab67 100644
--- a/ubifs-utils/fsck.ubifs/extract_files.c
+++ b/ubifs-utils/fsck.ubifs/extract_files.c
@@ -1030,7 +1030,11 @@ int file_is_valid(struct ubifs_info *c, struct scanned_file *file,
 
 		if (key_type(c, &dent_node->key) == UBIFS_XENT_KEY)
 			is_xattr = 1;
-		if (is_xattr != file->ino.is_xattr || type != dent_node->type)
+		if (is_xattr != file->ino.is_xattr)
+			list_add(&dent_node->list, &drop_list);
+		else if (type != dent_node->type &&
+			 !(is_xattr && dent_node->type == UBIFS_ITYPE_DIR))
+			/* Ensure backwards compatibility for ubifs partitions pre-v2.2.1 where type was "UBIFS_ITYPE_DIR" */
 			list_add(&dent_node->list, &drop_list);
 	}
 

[-- Attachment #4: Type: text/plain, Size: 144 bytes --]

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

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

[Zhihao Cheng]

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

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

[Devin Armstrong]

Hi Zhihao,

Thanks for the quick response. I agree, the type field in the old versions of mkfs.ubifs is wrong and rightly flagged by fsck.ubifs. However, I would like to push back about the way this type inconsistency is handled. The type difference between v2.1.1 and v2.3.1 does not mean the node is corrupted. This is a labelling change that is treated as corruption and the action that fsck.ubifs takes is to delete the node, which in our case is the encryption info. Do you think a more appropriate fix is to repair the node in place? i.e. have fsck.ubifs repair the node by changing the type from DIR to REG

To try and give more context, we have a large number of embedded devices in the field that were formatted with mkfs.ubifs v2.1.1 and if fsck.ubifs were run against these non-upgradable partitions, it would wipe the encryption information from the ubi partition. And since encryption is paramount for our devices, the device would simply fail to boot due to an unencrypted partition, leaving the device permanently bricked.

I believe fixing the type in place preserves your goal of not ignoring inconsistencies while also avoiding data loss where there isn't actually any corruption.

Please let me know your thoughts,

Best,
Devin

________________________________________
From: Zhihao Cheng <chengzhihao1@huawei.com>
Sent: August 26, 2026 7:10 PM
To: Devin Armstrong; linux-mtd@lists.infradead.org
Cc: Junghum Park; Wolfgang Tolkien
Subject: Re: mtd-utils: [BUG] fsck.ubifs backwards compatibility issue wipes ubi volume encryption information

[Caution] This email originated outside of Tantalus

This is the first time you received an email from this sender (chengzhihao1@huawei.com). Exercise caution when clicking links, opening attachments or taking further action, before validating its authenticity.

在 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 ./https://linkprotect.cudasvc.com/url?a=https%3a%2f%2ffsck_ubifs_reproduce_bug.sh&c=E,1,HwWSNjxDb4Jyi6Svubv4_rU_XXblAM5sl-SGW5gnPWBkek9xx1RZkIdBVsnBUxLDjH_E4giHec_5fveXphcc48M7bQdBQizqd2-e4-8MMQ,,&typo=1 --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://linkprotect.cudasvc.com/url?a=https%3a%2f%2fgit.infradead.org%2f%3fp%3dmtd-utils.git%3ba%3dcommit%3bh%3dd17b14d953b2ab56c938d6c7829b70b91c736efe&c=E,1,fSFm63jP5iXDZF6oguP_D6Dnsu-jSWIGtM0IU1q1M7Ks6IGRzpY4Q1MG_j0iqRWJIEIv5rOKZNFe8_f46iJ_DT7EuassTHgEodvrxN6a6pOKn8OV&typo=1

> 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
> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.tantalus.com&c=E,1,KxYAgvOSYMOTWGdye0Adt1F048oGFXnOpJah8_YTqn3b6A4MQdT4tyIv9gQ6A00P9wFm02BvBnXB6i20P5tEBLReYmPYuPi7H9rGvJoKyw,,&typo=1
>
> CONFIDENTIALITY NOTICE.&nbsp; 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.&nbsp; 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
> https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists.infradead.org%2fmailman%2flistinfo%2flinux-mtd%2f&c=E,1,Xh2NmZs7gefQx34TtrCEOwqEojHkrwcC4s3P8wZQAFW-F4oaZOFhE3eja3YeKpzd6xXRcGMSP66fqVHs7GNJ8E1BAmMNr9YJru9OI80OJrm0k08qiw,,&typo=1
>

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/

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

[Zhihao Cheng]

在 2026/8/28 1:21, Devin Armstrong 写道:
> Hi Zhihao,
> 
> Thanks for the quick response. I agree, the type field in the old versions of mkfs.ubifs is wrong and rightly flagged by fsck.ubifs. However, I would like to push back about the way this type inconsistency is handled. The type difference between v2.1.1 and v2.3.1 does not mean the node is corrupted. This is a labelling change that is treated as corruption and the action that fsck.ubifs takes is to delete the node, which in our case is the encryption info. Do you think a more appropriate fix is to repair the node in place? i.e. have fsck.ubifs repair the node by changing the type from DIR to REG
Hi Devin,
You can customize your own mtd-utils repository to fix the problematic  
image created by older versions of mkfs by changing the problematic dent  
node from a DIR type to a REG type. However, I do not recommend pushing  
this solution upstream to mtd-utils because this is a corruption issue  
that fsck needs to handle, and fsck cannot determine whether it was  
caused by mkfs or if there was a genuine problem.
> 
> To try and give more context, we have a large number of embedded devices in the field that were formatted with mkfs.ubifs v2.1.1 and if fsck.ubifs were run against these non-upgradable partitions, it would wipe the encryption information from the ubi partition. And since encryption is paramount for our devices, the device would simply fail to boot due to an unencrypted partition, leaving the device permanently bricked.
> 
> I believe fixing the type in place preserves your goal of not ignoring inconsistencies while also avoiding data loss where there isn't actually any corruption.
> 
> Please let me know your thoughts,
> 
> Best,
> Devin
> 
> ________________________________________
> From: Zhihao Cheng <chengzhihao1@huawei.com>
> Sent: August 26, 2026 7:10 PM
> To: Devin Armstrong; linux-mtd@lists.infradead.org
> Cc: Junghum Park; Wolfgang Tolkien
> Subject: Re: mtd-utils: [BUG] fsck.ubifs backwards compatibility issue wipes ubi volume encryption information
> 
> [Caution] This email originated outside of Tantalus
> 
> This is the first time you received an email from this sender (chengzhihao1@huawei.com). Exercise caution when clicking links, opening attachments or taking further action, before validating its authenticity.
> 
> 在 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 ./https://linkprotect.cudasvc.com/url?a=https%3a%2f%2ffsck_ubifs_reproduce_bug.sh&c=E,1,HwWSNjxDb4Jyi6Svubv4_rU_XXblAM5sl-SGW5gnPWBkek9xx1RZkIdBVsnBUxLDjH_E4giHec_5fveXphcc48M7bQdBQizqd2-e4-8MMQ,,&typo=1 --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://linkprotect.cudasvc.com/url?a=https%3a%2f%2fgit.infradead.org%2f%3fp%3dmtd-utils.git%3ba%3dcommit%3bh%3dd17b14d953b2ab56c938d6c7829b70b91c736efe&c=E,1,fSFm63jP5iXDZF6oguP_D6Dnsu-jSWIGtM0IU1q1M7Ks6IGRzpY4Q1MG_j0iqRWJIEIv5rOKZNFe8_f46iJ_DT7EuassTHgEodvrxN6a6pOKn8OV&typo=1
> 
>> 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
>> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fwww.tantalus.com&c=E,1,KxYAgvOSYMOTWGdye0Adt1F048oGFXnOpJah8_YTqn3b6A4MQdT4tyIv9gQ6A00P9wFm02BvBnXB6i20P5tEBLReYmPYuPi7H9rGvJoKyw,,&typo=1
>>
>> CONFIDENTIALITY NOTICE.&nbsp; 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.&nbsp; 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
>> https://linkprotect.cudasvc.com/url?a=http%3a%2f%2flists.infradead.org%2fmailman%2flistinfo%2flinux-mtd%2f&c=E,1,Xh2NmZs7gefQx34TtrCEOwqEojHkrwcC4s3P8wZQAFW-F4oaZOFhE3eja3YeKpzd6xXRcGMSP66fqVHs7GNJ8E1BAmMNr9YJru9OI80OJrm0k08qiw,,&typo=1
>>
> 
> 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/