Clamp blob range in RCTBlobManager instead of raising NSRangeException

[daledah]

Summary:

RCTBlobManager's resolve:offset:size: slices the stored NSData with the offset and size that come from the JS-side blob descriptor, without ever range-checking them against the data it actually holds:

if (offset != 0 || (size != -1 && size != data.length)) {
  data = [data subdataWithRange:NSMakeRange(offset, size)];
}

When the descriptor and the stored bytes disagree, subdataWithRange: raises NSRangeException. That is fatal rather than recoverable, because createFromParts:withId: runs on the TurboModule method queue (com.meta.react.turbomodulemanager.queue) with no JS frame on the stack to catch it, so the app is terminated.

This has been reported repeatedly since 2018 and is still unfixed on main:

• iOS Native Crash when uploading blobs using aws-sdk #27857 - range {0, 1769328} exceeds data length 458 (aws-sdk uploads). Closed by the bot in 2022 with the code unchanged.
• RCTBlobManager handleNetworkingRequest React native IOS #35096, App crashes when uploading blob with fetch API #21851, ReactNative app for iOS crashes when uploading blob  #21076, While uploading a blob using Fetch app crashes on iOS #20895 - the same crash from fetch/blob uploads.

What makes it worth guarding at the slice itself is that the reports come from at least three unrelated producers:

1. Blob data deallocated early while a slice still referenced it - fixed separately in Prevent native blob resource from being de-allocated prematurely #31392.
2. Strings truncated at an embedded NUL as they crossed into native, so the JS-recorded size exceeded the stored bytes - fixed separately in Fix Text truncation at NULL character on iOS and Android (#24129) #57906.
3. A race between writing a blob and sending it, discussed in RCTBlobManager handleNetworkingRequest React native IOS #35096 - still open.

Each of those was (or will be) fixed one at a time, and each time the symptom was a hard crash in the same three lines. A descriptor that disagrees with the stored bytes is a data bug; it should not be a fatal one.

What this changes

• resolve:offset:size: clamps the range to the bytes that are actually stored. An out-of-bounds offset returns nil; a size that overruns the available bytes is truncated to what is there. Both cases log via RCTLogWarn with the blob ID and the two lengths, so the underlying desync is visible instead of silent.
• size < 0 still means "the rest of the blob", preserving the existing -1 contract.
• createFromParts:withId: gains nil guards with the same logging. A part that fails to resolve, or a string part that fails to encode, previously contributed zero bytes with no signal at all - which is itself one of the ways a blob ends up shorter than its descriptor.

This also fixes a latent crash on the existing code path: with offset > 0 and size == -1, the old condition entered the branch and called NSMakeRange(offset, (NSUInteger)-1), which is an enormous length. resolveURL: defaults size to -1 when the query parameter is absent, so a blob: URL built by hand rather than by URL.createObjectURL would hit it.

Truncate rather than zero-pad

Android is already forgiving here - BlobModule.kt uses Arrays.copyOfRange, which zero-pads when the requested end is past the array, which is why this crash is iOS-only. This change deliberately truncates instead of matching that zero-padding: padding a short read with NUL bytes silently corrupts the payload with plausible-looking data, whereas a short read is at least a length mismatch that a server or a checksum can detect. Happy to switch to zero-padding for cross-platform symmetry if maintainers prefer it.

Changelog:

[IOS] [FIXED] - Clamp blob ranges in RCTBlobManager instead of raising NSRangeException

Test Plan:

The two producers above that have already been fixed cannot be used to reproduce this on main any more, so the repro below creates the descriptor/data disagreement directly. It is deterministic and does not depend on which producer caused it.

In RNTester, or any app:

// Native stores 318 bytes for this blob.
const real = new Blob(['A'.repeat(318)]);

// Hand it a descriptor that claims 321.
const lying = new Blob([]);
lying.data = {...real.data, size: 321};

// Consuming it goes createFromParts -> resolve: -> resolve:offset:size:
new Blob([lying]);

Before: the app terminates.

*** Terminating app due to uncaught exception 'NSRangeException', reason:
'*** -[NSConcreteMutableData subdataWithRange:]: range {0, 321} exceeds data length 318'

-[RCTBlobManager resolve:offset:size:]
-[RCTBlobManager resolve:]
-[RCTBlobManager createFromParts:withId:]
facebook::react::ObjCTurboModule::performVoidMethodInvocation(...)
_dispatch_workloop_worker_thread

After: the app stays up, the blob resolves to the 318 bytes that are actually stored, and the console shows:

[BlobManager] blob <uuid>: 321 bytes requested at offset 0, but only 318 are stored; truncating

Formatting:

node ./scripts/clang-format.js --check

[meta-cla]

Hi @daledah!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!