Re: [PATCH] udf: propagate error from udf_fiiter_add_entry

[Jan Kara]

On Tue 21-04-26 10:43:21, Tristan Madani wrote:
> On Mon, 20 Apr 2026, Jan Kara wrote:
> > Thanks for the patch. Did you analyze how it happened that the directory
> > iteration fixing up tags failed? Because if it fails like this, we have
> > practically wiped the directory which is not great. So if we are missing
> > some directory consistency check before we start converting it, it would be
> > good to add it instead of just failing like this later.
> 
> Good point. The syzbot reproducer uses a crafted filesystem image where
> the inline directory data passes inode loading but contains entries that
> fail udf_verify_fi() during iteration (e.g., bad tagIdent or CRC length
> mismatch).
> 
> The problem is that by the time we iterate in udf_expand_dir_adinicb()
> to fix up tagLocation, we've already changed the allocation type and
> moved the data to a new block. If the iteration then fails, the
> directory is in an inconsistent state.
> 
> The right fix would be to validate the inline directory entries
> BEFORE starting the conversion -- iterate once to verify all entries
> pass udf_verify_fi(), then proceed with the block allocation and tag
> fixup only if validation succeeds. That way we never start a
> destructive conversion on data we can't fully iterate.
> 
> I can send a v2 with this approach: a pre-conversion validation pass
> using udf_fiiter_init/advance (which calls udf_verify_fi internally),
> and only proceed if the full iteration succeeds. The error propagation
> from v1 would remain as a safety net in case anything goes wrong
> despite the pre-check.
> 
> Would that be the approach you have in mind?

Apparently you are running an AI agent to do the communication and coding.
That should be disclosed in Assisted-by: tag. Also I don't feel like
explaining to LLM how it should be doing the work. I could just do it
myself in this case.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR