tsepez: could you please take a look? Thanks!

https://cs.chromium.org/chromium/src/third_party/pdfium/core/fpdfapi/fpdf_parser/cpdf_security_handler.cpp?rcl=0&l=152 

keylen is set to zero (length from dict was 1).

  } else {
    keylen = Version > 1 ? pEncryptDict->GetIntegerBy("Length", 40) / 8 : 5;
  }
  if (keylen > 32 || keylen < 0) {
    return FALSE;
  }
  return TRUE;
}

Not sure if the check wanted to be <= 0 above, but a zero-length key seems like a legit possiblity.  The code is also probably wrong if we don't have a multiple of 8 bits.

Later on, CRYPT_ArcFourSetup assumes it has at least one byte of key

   j = (j + a + key[k]) & 0xFF;
 
Not sure if we care to fix this other than to avoid the warning, its a single byte that gets mixed in and whose value is unlikely to be of use as an infoleak.

The PDF spec indicates that the length value must be a multiple of 8, in the range 40 to 128. Default value: 40.  So the question is whether to enforce this, and risk breaking non-conforming documents in the wild ...

@dsinclair, @thestig, any opinion?

Over to Dan for resolution.

Do we know of any PDFs which break this assumption that aren't mal-formed? My vote would be that we fix it to follow the spec and if we get non-comforming PDFs we can update to make them work if they're valid.

ClusterFuzz testcase 4958327648026624 is flaky and no longer reproduces, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

Uh, looks like this got refiled as  bug 686128 ?

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot