Re: [PATCH v4 0/6] ntfs: validate attribute values on lookup
From: CharSyam
Date: Sat Jun 06 2026 - 20:00:36 EST
Hi Namjae,
Thanks for applying patches 0001 through 0004.
Skipping 0005/0006 for now makes sense. After re-checking the
generic/013 failure, I found that v4 only fixed one side of the
$INDEX_ROOT resize ordering. Patch 0005 handled the shrink side in
ntfs_ir_truncate(), but v4 missed the grow side in ntfs_ir_reparent():
the code could publish a larger index_length/allocated_size before the
resident value was grown. If that resize then hit -ENOSPC, the recovery
path could re-lookup a transiently inconsistent $INDEX_ROOT.
So 0005 was not intended as a workaround, but it was incomplete as a
prerequisite for the $INDEX_ROOT validator. I will send the remaining
$INDEX_ROOT work as a small v5 follow-up series on top of the tree with
0001-0004 applied.
For the allocated_size question: the driver currently consumes
index.allocated_size as the usable capacity of the shared index_header,
including resident $INDEX_ROOTs. ntfs_ie_add() uses it to decide whether
an insertion can be done in place or whether the root has to grow, and
ntfs_ie_insert() does not re-check the resident value boundary. So I
think the validator should still reject allocated_size values that extend
past the resident index area.
The extent-inode lifetime race I found while testing is independent, so
I will send that separately instead of mixing it into this series.
Thanks,
DaeMyung
2026년 6월 6일 (토) 오전 12:30, Namjae Jeon <linkinjeon@xxxxxxxxxx>님이 작성:
>
> On Sat, May 30, 2026 at 11:35 PM DaeMyung Kang <charsyam@xxxxxxxxx> wrote:
> >
> > This v4 supersedes the previous single-patch v3. Per review, it expands
> > the lookup-time attribute value validation into a series so $VOLUME_NAME
> > and $INDEX_ROOT can be validated safely.
> >
> > The first patch keeps the original $FILE_NAME corruption fix and moves
> > the duplicated non-resident mapping-pairs metadata checks into the common
> > attribute value validator. It also keeps resident value matching in the
> > external attribute lookup path on the actual value length and fixes the
> > matching attrlist duplicate check for resident attributes. The next
> > patches prepare the volume label write and mount read paths to cope with
> > a rejected $VOLUME_NAME, add $VOLUME_NAME validation, fix the
> > ntfs_ir_truncate() shrink ordering issue, and then enable $INDEX_ROOT
> > validation.
> >
> > Changes since v3:
> > - Expand the single patch into a 6-patch series as requested.
> > - Keep corruption messages using numeric attribute types and drop the
> > attribute type name helper.
> > - Move non-resident mapping-pairs metadata validation into the shared
> > ntfs_attr_value_is_valid() helper.
> > - Preserve resident @val matching in ntfs_external_attr_find() using the
> > actual resident value length, and avoid reading the non-resident
> > lowest_vcn union member when checking resident attrlist duplicates.
> > - Make ntfs_write_volume_label() add a replacement only after successful
> > removal or after -ENOENT, and propagate other lookup/removal errors.
> > - Reinitialize the mount-time search context before the
> > $VOLUME_INFORMATION lookup, since a rejected $VOLUME_NAME leaves the
> > context in an undefined state.
> > - Add $VOLUME_NAME-specific validation, and reject non-resident
> > $VOLUME_NAME records like non-resident $FILE_NAME.
> > - Include the ntfs_ir_truncate() shrink ordering fix.
> > - Add $INDEX_ROOT-specific validation on top of the shrink fix.
> >
> > DaeMyung Kang (6):
> > ntfs: validate attribute values on lookup
> > ntfs: do not replace volume name after lookup errors
> > ntfs: reinit search context before volume information lookup
> > ntfs: validate resident volume name values on lookup
> > ntfs: update index root allocated size before shrink
> > ntfs: validate resident index root values on lookup
> I have applied patches 0001 ~ 0004 first, as we are continuously
> receiving similar patches. I skipped patch 0005 for now since it seems
> like a workaround, and as you know, 0006 patch couldn't be applied due
> to xfstests failures.
> Thanks!