[PATCH v2] erofs-utils: lib: validate algorithm for encoded extents

[Utkal Singh]

Hi Yifan,

Thank you for the guidance and for clarifying the review workflow.

Understood. I will consolidate related fixes into proper patch
series with a cover letter in future submissions instead of
sending individual patches.

I will also follow the versioning conventions (v2/v3 for updates
and RESEND for unchanged resubmissions) and adopt the backport
commit message format described in commit ee2709, including
square bracket annotations where applicable.

Thanks again for the review and suggestions.

Best regards,
Utkal Singh

On Mon, 16 Mar 2026 at 08:41, Yifan Zhao <yifan.yfzhao at foxmail.com> wrote:

> Hi Utkal Singh,
> Thank you for your contributions and the recent fixes.
> To help us manage the review process more effectively and avoid confusion
> with duplicate emails,
> could you please consolidate these random fixes into a *single patch
> series with a cover letter* in the future?
> This allows us to track the entire set of changes in one thread.
> Additionally, please follow these conventions for follow-ups:
>
>    1. *Versioning:* If you modify a patch based on review feedback,
>    please increment the version prefix (e.g., v2, v3) in the subject line.
>    2. *Resends:* If you are simply resending a patch without changes
>    (e.g., to bump it), please add a *RESEND* prefix to the subject line
>    instead of treating it as a new version.
>
> This will greatly help in tracking which patches need to be merged.
> Regarding backporting patches to the kernel, please refer to commit ee2709
> in the erofs-utils repository for the preferred commit message format.
> Specifically, please use square brackets [] to describe any modifications
> you made to the source kernel commit during the backport process.
> [ Gao may follow up with additional workflow details if needed. ]
> Thanks again for your help.
>
> Yifan Zhao
>
>
> On 3/15/2026 10:22 PM, Utkal Singh wrote:
>
> Encoded extents use fmt field as algorithm index without checking
> available_compr_algs bitmask. The non-encoded path already has this
> check but the encoded extent path in z_erofs_map_blocks_ext() was
> missing equivalent validation.
>
> Add available_compr_algs consistency check for encoded extents,
> following kernel commit 131897c65e2b.
>
> Signed-off-by: Utkal Singh <singhutkal015 at gmail.com> <singhutkal015 at gmail.com>
> ---
>  lib/zmap.c | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/lib/zmap.c b/lib/zmap.c
> index 0e7af4e..a8d1ca6 100644
> --- a/lib/zmap.c
> +++ b/lib/zmap.c
> @@ -630,8 +630,17 @@ static int z_erofs_map_blocks_ext(struct erofs_inode *vi,
>  			if (map->m_plen & Z_EROFS_EXTENT_PLEN_PARTIAL)
>  				map->m_flags |= EROFS_MAP_PARTIAL_REF;
>  			map->m_plen &= Z_EROFS_EXTENT_PLEN_MASK;
> -			if (fmt)
> -				map->m_algorithmformat = fmt - 1;
> +			if (fmt) {
> +				unsigned int afmt = fmt - 1;
> +
> +				if (afmt >= Z_EROFS_COMPRESSION_MAX ||
> +				    !(sbi->available_compr_algs & (1 << afmt))) {
> +					erofs_err("unknown algorithm %u for encoded extent, nid %llu",
> +						  afmt, vi->nid | 0ULL);
> +					return -EOPNOTSUPP;
> +				}
> +				map->m_algorithmformat = afmt;
> +			}
>  			else if (interlaced && !((map->m_pa | map->m_plen) & bmask))
>  				map->m_algorithmformat =
>  					Z_EROFS_COMPRESSION_INTERLACED;
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linux-erofs/attachments/20260316/760aa9fc/attachment.htm>