theobisproject commented on pull request #120:
URL: https://github.com/apache/commons-compress/pull/120#issuecomment-674373279
I am using this project https://github.com/rohanpadhye/jqf to do the fuzzing
via the AFL bridge provided. This was the fuzz method implementation I used
```java
theobisproject commented on pull request #120:
URL: https://github.com/apache/commons-compress/pull/120#issuecomment-673640854
In the files I got from the fuzzing I noticed that even the array creation
can lead to an OOM exception. I tried to replace it with a list and let it grow
as
theobisproject commented on pull request #120:
URL: https://github.com/apache/commons-compress/pull/120#issuecomment-671175522
The test files @akelday attached to the jira issue are replicating the
issue. Since this issue is dependend on the available Java heap it could be
difficult to
theobisproject commented on pull request #120:
URL: https://github.com/apache/commons-compress/pull/120#issuecomment-669688765
Just a short update. I will try to generate a reproducting file via fuzzing
which is hopefully successful. This might take some days but I think at the end
of the
theobisproject commented on pull request #120:
URL: https://github.com/apache/commons-compress/pull/120#issuecomment-668600127
> My biggest issue with this PR is that it is missing a unit test. Without a
failing unit test, there is no way to know that this fixes anything or that a
future
theobisproject commented on pull request #120:
URL: https://github.com/apache/commons-compress/pull/120#issuecomment-668591608
As you are a bit more familiar with the 7z archive maybe you have an idea
how to avoid the entry allocation completely before we are sure the header is
not
theobisproject commented on pull request #120:
URL: https://github.com/apache/commons-compress/pull/120#issuecomment-668585383
Hi @PeterAlfredLee
as explained in the Jira Ticket it was a corrupted archive where the
`numFiles` variable read from the header in `readFilesInfo` was about
