tunn3l

Hello, Thanks in advance for your effort. I can indeed confirm this claim and look forward to make this project more secure!

update: apparently the same type of bug also affects .pandore files

Hello, Thanks for responding. Regarding the question if crash.bmp is still valid: I get: ``` user@lnx:/mnt/c/Users/user/Desktop/cimg_fuzz_prod_finds/bmp_RAM_exhaustion$ uname -a Linux lnx 5.10.16.3-microsoft-standard-WSL2 #1 SMP Fri Apr 2 22:23:49 UTC 2021 x86_64...

Regarding https://github.com/dtschump/CImg/commit/619cb58dd90b4e03ac68286c70ed98acbefd1c90, I think this wont work when reading a virtual file buffer (``FILE*``). Because of ``cimg::type::max()``, the maximum size ist a very large number (18446744073709551615 on my system), allowing...

Ah thanks, I see the problem here. How about making the limit user controllable? It could have an initial value and then be user stettable. Im thinking of something like...

I agree! ^^ Now I wonder if this limit should also be used in other places, but at the moment I dont have time to investigate. Maybe one could integrate...

okay so the old crashing images do not crash anymore 👍 However, I have found another pandore sample, that also crashes wih RAM exhaustion and seems to get around the...

Hello again, The statement that I've made about pandore files is wrong. It was a mistake on my end. **The fix seems to prevent RAM exhaustion in both filetypes** ✔️...

Hello, there is a small update: I've been investigating the loading process a bit more and actually found a bypass for the proposed fix. It has to do with buffers...

would also be very nice for it to be a per-language togglable feature.