Bugzilla

This appears to be a bounds-overrun due to (most likely) a corrupt jar file.  Comment from a user indicates it's a repeatable startup crash for them (Mac).

Most crashes are Mac ESR78; the crashes are from Android 94+, and Mac 106.  (plus a single Mac 80 crash).

```
uint32_t len = mFd->mLen;
  const uint8_t* data = mFd->mFileData;
  offset = aItem->LocalOffset();

  if (len < ZIPLOCAL_SIZE || offset > len - ZIPLOCAL_SIZE) return 0;
 // -- check signature before using the structure, in case the zip file is
  // corrupt
  ZipLocal* Local = (ZipLocal*)(data + offset);

->  if ((xtolong(Local->signature) != LOCALSIG)) return 0;
```
From that, my guess is that offset is corrupt, and we're indexing past the end of the data.  There is a check for out of bounds -- but only checks if offset points past the buffer, not that offset points to enough before the buffer for local->signature to be fetchable safely.

This appears to be a bounds-overrun due to (most likely) a corrupt jar file.  Comment from a user indicates it's a repeatable startup crash for them (Mac).

Most crashes are Mac ESR78; the crashes are from Android 94+, and Mac 106.  (plus a single Mac 80 crash).

```
uint32_t len = mFd->mLen;
  const uint8_t* data = mFd->mFileData;
  offset = aItem->LocalOffset();

  if (len < ZIPLOCAL_SIZE || offset > len - ZIPLOCAL_SIZE) return 0;
 // -- check signature before using the structure, in case the zip file is
  // corrupt
  ZipLocal* Local = (ZipLocal*)(data + offset);

->  if ((xtolong(Local->signature) != LOCALSIG)) return 0;
```
From that, one guess is that offset is corrupt, and we're indexing past the end of the data somehow.   We shouldn't be, since there is a length check, and it subtracts the length of ZipLocal for the check.   Perhaps there's an issue with the data for the Zip, and for some reason the memory referenced by mFd isn't accessible.