UBIFS bug: failure to read NNODE while initializing LPT on mount

Thu Feb 26 11:33:20 PST 2026

Hi,

I have a problem when mounting a UBIFS volume on a MIPS I6400-based board.
The Linux version we are running is 4.19.124.
I ran several MTD tests and no issues were found among multiple boards using the same HW/SW.

The issue is that during mounting, when initializing the LPT, during ubifs_lpt_lookup, we attempt to read an NNODE
And it cannot be read.

[    4.399569] ubi0: attaching mtd6 
[    4.684372] ubi0: scanning is finished 
[    4.719332] ubi0: attached mtd6 (name "FILESYSTEM", size 413 MiB) 
[    4.725448] ubi0: PEB size: 32768 bytes (32 KiB), LEB size: 32640 bytes 
[    4.732069] ubi0: min./max. I/O unit sizes: 1/256, sub-page size 1 
[    4.738257] ubi0: VID header offset: 64 (aligned 64), data offset: 128 
[    4.744791] ubi0: good PEBs: 13232, bad PEBs: 0, corrupted PEBs: 0 
[    4.750978] ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128 
[    4.758209] ubi0: max/mean erase counter: 2/0, WL threshold: 4096, image sequence number: 1841776491 
[    4.767348] ubi0: available PEBs: 0, total reserved PEBs: 13232, PEBs reserved for bad PEB handling: 0 
[    4.776697] ubi0: background thread "ubi_bgt0d" started, PID 458 
UBI device number 0, total 13232 LEBs (431892480 bytes, 411.8 MiB), available 0 LEBs (0 bytes), LEB size 32640 bytes (31.8 KiB) 
[    4.791418] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" started, PID 460 
[    4.793360] UBIFS (ubi0:0): recovery needed 
[    4.793961] UBIFS error (ubi0:0 pid 459): check_lpt_type.constprop.9: invalid type (15) in LPT node type 1 
[    4.793976] CPU: 5 PID: 459 Comm: mount Not tainted 4.19.124.epg_ssnt-22.04-123-39-g821ddb1fb5-rt53 #1 
[    4.793982] Stack : a8000008013a25a0 a80000087b6579f8 a800000801166534 00000000013a0000 
[    4.793998]         1d4bc3d135650872 0000000000000000 a80000087b657938 a800000801760000 
[    4.794011]         00000000013a0000 0000000000000001 0000000000000002 0000000000000001 
[    4.794024]         0000000000000000 a80000087b657a88 a800000800944490 a8000008008202cc 
[    4.794037]         a800000800944490 a8000008013a0000 ffff000000000000 a800000801450000 
[    4.794050]         0000000000000001 a80000087ff8d028 000000000000000a a80000087ff8e100 
[    4.794063]         0000000000000000 a800000801730000 a800000801730000 3d64000021f7e82f 
[    4.794076]         0000000000000001 a80000087b654000 a80000087b657930 a80000087b657930 
[    4.794089]         a800000801166534 000000001401fce0 0000000000000000 0000000000000000 
[    4.794102]         c000000000130000 0000000080800008 a800000800812c30 1d4bc3d135650872 
[    4.794115]         ... 
[    4.794124] Call Trace: 
[    4.794139] [<a800000800812c30>] show_stack+0xc0/0x188 
[    4.794154] [<a800000801166534>] dump_stack+0x104/0x170 
[    4.794164] [<a800000800c08274>] check_lpt_type.constprop.9+0x84/0x90 
[    4.794173] [<a800000800c0a2d4>] ubifs_unpack_nnode+0x74/0x140 
[    4.794182] [<a800000800c0a7e0>] ubifs_read_nnode+0x210/0x278 
[    4.794190] [<a800000800c0a9b8>] ubifs_lpt_lookup+0xa8/0x1f0 
[    4.794199] [<a800000800c0b0b4>] ubifs_lpt_init+0x1cc/0xaf0 
[    4.794212] [<a800000800be7fd8>] ubifs_mount+0x1518/0x2480 
[    4.794223] [<a800000800a77214>] mount_fs+0x5c/0x238 
[    4.794234] [<a800000800a9f19c>] vfs_kern_mount.part.9+0x6c/0x1a8 
[    4.794244] [<a800000800aa30b4>] do_mount+0x734/0xe08 
[    4.794252] [<a800000800aa3b60>] ksys_mount+0xb0/0x158 
[    4.794261] [<a800000800aa3c28>] sys_mount+0x20/0x38 
[    4.794271] [<a8000008008251b0>] syscall_common+0x44/0x68 
[    4.794292] UBIFS error (ubi0:0 pid 459): ubifs_read_nnode: error -22 reading nnode at 10:0 
[    4.794301] CPU: 5 PID: 459 Comm: mount Not tainted 4.19.124.epg_ssnt-22.04-123-39-g821ddb1fb5-rt53 #1 
[    4.794304] Stack : a8000008013a25a0 a80000087b657a78 a800000801166534 00000000013a0000 
[    4.794318]         1d4bc3d135650872 0000000000000000 a80000087b6579b8 a800000801760000 
[    4.794331]         00000000013a0000 0000000000000001 0000000000000002 0000000000000001 
[    4.794344]         0000000000000000 a80000087b657b08 a800000800944490 a8000008008202cc 
[    4.794357]         a800000800944490 a8000008013a0000 ffff000000000000 a800000801450000 
[    4.794370]         0000000000000001 a80000087ff8d028 000000000000000a a80000087ff8e100 
[    4.794383]         0000000000000000 a800000801730000 a800000801730000 3d64000021f7e82f 
[    4.794395]         0000000000000001 a80000087b654000 a80000087b6579b0 a80000087b6579b0 
[    4.794408]         a800000801166534 000000001401fce0 0000000000000000 0000000000000000 
[    4.794421]         c000000000130000 0000000080800008 a800000800812c30 1d4bc3d135650872 
[    4.794434]         ... 
[    4.794441] Call Trace: 
[    4.794449] [<a800000800812c30>] show_stack+0xc0/0x188 
[    4.794457] [<a800000801166534>] dump_stack+0x104/0x170 
[    4.794466] [<a800000800c0a6f8>] ubifs_read_nnode+0x128/0x278 
[    4.794475] [<a800000800c0a9b8>] ubifs_lpt_lookup+0xa8/0x1f0 
[    4.794484] [<a800000800c0b0b4>] ubifs_lpt_init+0x1cc/0xaf0 
[    4.794493] [<a800000800be7fd8>] ubifs_mount+0x1518/0x2480 
[    4.794501] [<a800000800a77214>] mount_fs+0x5c/0x238 
[    4.794510] [<a800000800a9f19c>] vfs_kern_mount.part.9+0x6c/0x1a8 
[    4.794518] [<a800000800aa30b4>] do_mount+0x734/0xe08 
[    4.794527] [<a800000800aa3b60>] ksys_mount+0xb0/0x158 
[    4.794535] [<a800000800aa3c28>] sys_mount+0x20/0x38 
[    4.794543] [<a8000008008251b0>] syscall_common+0x44/0x68 
[    5.152479] UBIFS (ubi0:0): background thread "ubifs_bgt0_0" stops

I have not managed to replicate this issue, however, I think it is related to an early garbage collection of an LPT LEB that still contains live nodes.
One such flow is this: 
1. In ubifs_lpt_start_commit,  if (c->check_lpt_free) evalutes to true and we begin clearing space.
2. We call on lpt_gc(…) and it selects the victim LEB, LEB X. LEB X contains LSAVEs, LTABs, NNODEs and PNODEs. 
In this LPT LEB X, only one NNODE is live, and the rest of the nodes are obsolete. We call lpt_gc_num(…, X). 
This live NNODE is connected to other live NNODEs or PNODEs found on another LPT LEB.
3. We run over every node in LPT LEB X, and since we mark the singular live NNODE as dirty. This does not increment c->dirty_pn_cnt.
4. LPT LEB X gets marked for trivial GC in ubifs_lpt_start_commit -> lpt_gc_start.
5. Since we did not increment c->dirty_pn_cnt, we hit the early return in ubifs_lpt_start_commit,
and we don't proceed to do get_cnodes_to_commit, or layout_cnodes.
6. Post commit, we have a live NNODE on a LPT LEB X, despite it having been garbage collected. 
On the next start up, when initializing the LPT, LPT LEB X is unmapped, but the master still thinks there's a live NNODE at some offset there.
Alternatively, it can be allocated again after garbage collection, 
and we might be pointing to incorrect data (the middle of some other, live data), or in the worst case, an actual live NNODE that is not the original.

Is there anything that stops this flow from happening on rare occasions, or can this flow not even happen at all?
I would appreciate your help regarding the issue, and the flow described above.

Thanks,
Azar 