[v6.0] fix(provider-utils): bound media-type sniffing decode for ID3-prefixed input - #17725
Conversation
Bugfix reviewOutcome: approved Fixes issueStatus: fully-addresses Detection now decodes only fixed-size prefixes, uses zero-copy Uint8Array views, preserves MP3 detection at the configured ID3 boundary, and returns undefined beyond that boundary. Side effectsRisk: low Normal signature detection remains limited to the existing 18-byte prefix; the only intentional behavior change is that ID3 tags beyond the fixed scan boundary no longer auto-detect. PerformanceRisk: low Base64 work is capped at approximately 128 KiB for ID3 input and 18 bytes otherwise, while raw-byte handling uses subarray views rather than attachment-sized copies. Backwards compatibilityRisk: low No stored bytes are modified. Existing oversized ID3 attachments may require an explicitly supplied media type when reprocessed, which is the issue's specified fallback. ArchitectureRisk: none The backport changes the existing media-detection utility in the owning ai package and consumes provider utilities through their declared package export, without cross-package src access or new coupling. Change scopeStatus: minimal The three changed files are limited to the detection implementation, focused boundary regression tests, and the required patch changeset. SecurityRisk: none The change reduces resource-exhaustion exposure, bounds malformed size-field handling, and introduces no new parsing, injection, or data-access surface. TestingStatus: appropriate Tests cover ordinary and ID3-tagged MP3s, raw/base64 parity at and beyond the scan boundary, and the existing image and audio signature controls. VerificationInspected every diff hunk and relevant caller; the 48-test detection suite passed in Node and Edge configurations, ai package type checking passed, repository formatting and lint checks passed, and a focused large-input probe confirmed bounded decoding and safe malformed-size handling. The linked ID3 specification was also reviewed. Relevant Documentation |
|
🚀 Published in:
|
2 participants
Summary
Media-type sniffing is documented as an O(1) check on the first ~18 bytes (24 base64 chars). An
ID3/SUQz-prefixed attachment bypassed that bound:stripID3TagsIfPresentran before the truncation and decoded the entire base64 attachment (plus a full-size.slice()copy), then returned aUint8Arrayso the 24-char cap was skipped. A 4-character prefix flipped intended O(1) sniffing into an O(N) decode + copy of the whole attachment, on every path including image detection.Hardening
ID3) instead of the base64 string (startsWith('SUQz')), so string and raw-byte inputs are checked uniformly and base64 alignment tricks cannot fool it.Uint8Arraypath is bounded too, andstripID3usessubarray(a view) instead ofslice(a full copy), removing the second O(N) copy.ID3_MAX_SCAN_BYTES(128 KB), large enough to cover typical tags with embedded cover art while keeping cost constant in attachment size.Happy path
audio/mpeg.data:URLs, base64url,ArrayBuffer,Buffer, andtextinputs are normalized upstream and behave the same.Unhappy path
ID3/SUQz-prefixed attachment (benign or crafted) now decodes at most ~128 KB regardless of attachment size, so sniffing stays constant-time instead of scaling with the input.resolveFullMediaTypethrows its existing "must specify subtype" error if none was provided). RaiseID3_MAX_SCAN_BYTESif larger tags must be detected; cost stays O(1) either way.id3Sizecannot read out of bounds:subarrayclamps to length and returns empty, so no signature matches and detection returnsundefined.Testing
detect-media-typesuite passes (67 tests).Fixes #17709
Related Issues
Backport of #17386