[Patch Tracking] Hardening fixes for decompression and xattr parsing

[Utkal059]

Hi Gao Xiang,

As requested, here is a consolidated list of my pending patches with lore links.

Patch series 1: ZSTD decompression safety (v2, 2 patches)

https://lore.kernel.org/linux-erofs/20260317045537.9591-1-singhutkal015@gmail.com/

• [PATCH v2 1/2] erofs-utils: lib: validate ZSTD frame content size in decompression
• [PATCH v2 2/2] erofs-utils: lib: return error on ZSTD decompression length mismatch

Status: v2 sent with reproducer per maintainer request.

Patch: xattr shared count validation

https://lore.kernel.org/linux-erofs/20260316201919.41839-1-singhutkal015@gmail.com/

• [PATCH] erofs-utils: lib: validate h_shared_count in erofs_init_inode_xattrs()

Status: Review feedback received. Will resend as v2 with:

• Multiplication-based bounds check (avoid division)
• Refined commit message (clarify as hardening, no stability impact)
• Reproducer

Best regards,
Utkal Singh

[hsiangkao]

Could you please just update the issue message pointing to the latest patches in https://lore.kernel.org/linux-erofs ?

[Utkal059]

Thanks! I've updated the issue to point to the latest patches on lore.kernel.org.

Please let me know if anything else needs to be adjusted.

[hsiangkao]

@Utkal059 again, I don't accept any patch which fixes potential issue without any valid reproducer or add arbitary checks, the principle is below:

1. the image out-of-bound read of corrupted images is fine [also you shouldn't consider them as corrupted as long as they can be parsed in the correct way; the corrupt image is very subjective concept, many large values seem corrupt at the first glance but they can be valid. At the same time, the checksums look correct but the image can be corrupted and even malicious], as long as it won't cause memory issues or likewise; because the image is already corrupted; if it cause the memory issues, we should fix the memory issue rather than adding arbitary check.
2. if the value is insanely large (like i_size or z_extents), it can still be valid, but it takes time; so it won't be an issue too as long as users can interupt the process; please don't add any arbitary meaningless check for this because they are valid numbers.