linux-kernel - Re: [RESEND]: Kernel 4.14: SQUASHFS error: unable to read xattr id index table

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 17 May 2021 17:04:57 +0530
From:   Pintu Agarwal <pintu.ping@...il.com>
To:     phillip@...ashfs.org.uk
Cc:     open list <linux-kernel@...r.kernel.org>, sean@...nix.com,
        linux-mtd@...ts.infradead.org, linux-fsdevel@...r.kernel.org
Subject: Re: [RESEND]: Kernel 4.14: SQUASHFS error: unable to read xattr id
 index table

On Sat, 15 May 2021 at 03:21, Phillip Lougher <phillip@...ashfs.org.uk> wrote:
>
> Your kernel (4.14.170) was released on 5 Feb 2020, and so it won't
> contain any of the above commits. The xattr -id code in 4.14.170,
> was last updated in May 2011, and so it is much more likely the
> problem is elsewhere.
>
Okay this seems to be UBI volume flashing issue then. I will also try
with non-squashfs image (just ubifs).
See the result in the end.

> The xattr id index table is written to the end of the Squashfs filesystem,
> and it is the first table read on mounting.
>
Okay this gives me a clue that there are some corruptions while
writing the leftover blocks in the end.

> 1. Check the Squashfs filesystem for correctness before writing it to
> the flash. You can run Unsquashfs on the image and see if it reports
> any errors.
>
Can you give me some pointers on how to use unsquashfs ? I could not
find any unsquashfs command on my device.
Do we need to do it on the device or my Ubuntu PC ? Are there some
commands/utility available on ubuntu ?

> 2. You need to check the filesystem for integrity after writing it to
> the flash. Compute a checksum, and compare it with the original
> checksum.
>
Can you also guide me with an example, how to do this as well ?

BTW, I also tried "rootfs" volume flashing using "ubifs" image (non
squashfs). Here are the results.
a) With ubifs image also, the device is not booting after flashing the volume.
b) But I can see that the "rootfs" volume could be mounted, but later
gives some other errors during read_node.

These are the boot up errors logs:
{{{
[ 4.600001] vreg_conn_pa: dis▒[ 4.712458] UBIFS (ubi0:0): UBIFS:
mounted UBI device 0, volume 0, name "rootfs", R/O mode
[ 4.712520] UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB),
min./max. I/O unit sizes: 4096 bytes/4096 bytes
[ 4.719823] UBIFS (ubi0:0): FS size: 113008640 bytes (107 MiB, 445
LEBs), journal size 9404416 bytes (8 MiB, 38 LEBs)
[ 4.729867] UBIFS (ubi0:0): reserved for root: 0 bytes (0 KiB)
[ 4.740400] UBIFS (ubi0:0): media format: w4/r0 (latest is w5/r0),
UUID xxxxxxxxx-xxxxxxxxxx, small LPT model
[ 4.748587] VFS: Mounted root (ubifs filesystem) readonly on device 0:16.
[ 4.759033] devtmpfs: mounted
[ 4.766803] Freeing unused kernel memory: 2048K
[ 4.805035] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node type
(255 but expected 9)
[ 4.805097] UBIFS error (ubi0:0 pid 1): ubifs_read_node: bad node at
LEB 336:250560, LEB mapping status 1
[ 4.812401] Not a node, first 24 bytes:
[ 4.812413] 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ........................
}}}

Seems like there is some corruption in the first 24 bytes ??


Thanks,
Pintu