Hi,
I guess it depends on what you define as "reasonable". Depending on the malformed file and setup, they may take minutes to load (given that enough (virtual) memory is available to load all the truncated samples). The test cases that were generated by American Fuzzy Lop were about 5KB in size and took about 10 seconds to load on my machine, which I would say is quite excessive for such a tiny file, but those examples can be modified (by adding more malformed sample slots) to extend the loading time from seconds to minutes while still being about 5KB.To give some perspective, I don't just use libopenmpt on Desktop systems but also to scan module data in a server application where users can upload their own modules, and if a user could keep a server request busy for a minute (while also wasting tons of memory and CPU time), that server could be DOSed very easily. Thus I'd strongly suggest to include those two patches.I see, that is quite a long time to wait! Do you have these testcases so I can try them? My only concern is that p3 is pretty big so it has the potential of causing a regression. p5 looks fine.
I have attached some manually-crafted worst-case files to demonstrate the issue. For maximum effect, a 64-bit build has to be used, because otherwise memory allocation will fail fairly quickly and the malformed sample data won't even be attempted to be decoded.
p3 is smaller than it looks since some of it is just moving around things and as a consequence re-indenting them. The actual decoding logic is not modified. A diff without whitespaces should show this.
Cheers, Johannes
hangs.7z
Description: Binary data
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
