Skip to content

Reject unsupported external iloc data references#3206

Open
jmestwa-coder wants to merge 1 commit into
AOMediaCodec:mainfrom
jmestwa-coder:iloc-data-reference-validation
Open

Reject unsupported external iloc data references#3206
jmestwa-coder wants to merge 1 commit into
AOMediaCodec:mainfrom
jmestwa-coder:iloc-data-reference-validation

Conversation

@jmestwa-coder
Copy link
Copy Markdown

libavif currently supports same-file item extents and idat extents only.

iloc.data_reference_index values were previously parsed but ignored, causing extents declared as external references to be interpreted as same-file offsets.

This change rejects unsupported nonzero data_reference_index values during iloc parsing so downstream extent handling operates under validated source-boundary assumptions.

Changes

  • Reject nonzero iloc.data_reference_index values in avifParseItemLocationBox()
  • Add a regression test covering unsupported external data references

Test

  • Mutate white_1x1.avif to set data_reference_index = 1
  • Verify parsing now fails with AVIF_RESULT_BMFF_PARSE_FAILED
  • Existing IlocTest.TwoExtents continues to pass

Comment thread src/read.c
if (dataReferenceIndex != 0) {
avifDiagnosticsPrintf(diag, "Item ID [%u] contains an unsupported data reference index [%u]", itemID, dataReferenceIndex);
return AVIF_RESULT_BMFF_PARSE_FAILED;
}
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the pull request. ISO/IEC 14496-12:2022 Clause 8.11.3 (Item location box) does not require or recommend that data_reference_index be set to 0 when this field is not used. Therefore I think it is better to simply ignore this field.

Note that the value 0 is a valid value for data_reference_index, so one can argue that the value 0 can't really be used to indicate that the field is not used.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a closer look. I think the condition at line 2057 should also check that construction_method is equal to 0:

        if (constructionMethod == 0 && dataReferenceIndex != 0) {

But it is not clear what value constructionMethod should be set to for version 0. Do you know?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking a closer look.

From what I understand, construction_method is only explicitly present starting from iloc version 1/2, so for version 0 I’m not fully sure what the intended interpretation should be either.

I’ve updated the test to make the fixture assumptions explicit before mutating data_reference_index.

// data_reference_index field follows the item_ID field.
ASSERT_EQ(iloc_position[4], 0);
iloc_position[14] = 0;
iloc_position[15] = 1;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest also verifying data_reference_index is equal to 0 before changing it to 1:

   ASSERT_EQ(iloc_position[4], 0);
+  ASSERT_EQ(iloc_position[14], 0);
+  ASSERT_EQ(iloc_position[15], 0);
   iloc_position[14] = 0;
   iloc_position[15] = 1;

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I verified the fixture layout and added assertions checking the original data_reference_index value before mutating it.

@jmestwa-coder jmestwa-coder force-pushed the iloc-data-reference-validation branch from 624503a to ad149e3 Compare May 23, 2026 08:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants