Re: [PATCH] udf: propagate error from udf_fiiter_add_entry

[Tristan Madani <tristmd@gmail.com>]

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?

Thanks,
Tristan