ppkarwasz commented on PR #4274: URL: https://github.com/apache/logging-log4j2/pull/4274#issuecomment-5897498215
> But the reason for rejecting the single blob applies here too. Each element wrapper is a `byte[]` read by `in.readObject()` on the outer stream, at a length the JDK trusts. I patched that length in a 103 byte `ObjectMessage` from 12 to 400 million and both filter paths give `OutOfMemoryError` under `-Xmx64m`. Can we bound `filterInfo.arrayLength()` in `DefaultObjectInputFilter` instead? You are right. This PR only bounds the `new Object[]` allocation that Log4j performs itself, but when our wrapped objects are deserialized, the JDK still calls `new byte[untrustedLength]`. Only the user can limit that allocation, with an `ObjectInputFilter` that bounds the size of arrays. That is an explicit choice: I am concerned about what reporters can attribute to Log4j and I am not interested in making deserialization of untrusted data safe. This is a lost cause. Interestingly, [`InputStream#readNBytes`](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/io/InputStream.html#readNBytes(int)) does not pre-allocate an array of the requested size: passing `Integer.MAX_VALUE` does not cause an `OutOfMemoryError`, unless the stream actually contains that much data. `ObjectInputStream` takes a different approach and pre-allocates each array based on its declared length. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
