* Daniel Stenberg <dan...@haxx.se> [2025-02-05 09:21]: [...] > This problem can only trigger when using a run-time zlib version 1.2.0.3 or > older. zlib 1.2.0.4 was relased on August 10, 2003. This means zlib versions > that do not trigger this problem have been available and used for more than > twenty-one years already. A zlib version 1.2.0.3 or earlier still in use is > vulnerable to a wide range of security problems and a user using this is > already in a spectacularly bad position. > > libcurl featured code that at run-time takes a different code path for zlib > versions before 1.0.2.4 because of lack of functionality in those old > versions, and this rarely used piece of code contained the vulnerable code > path.
I assume this last version should have been 1.2.0.4 as before and not 1.0.2.4? [...] > SOLUTION > ------------ > > Starting in version 8.12.0, libcurl no longer supports zlib < 1.2.0.4. Using > such a version will now instead cause a run-time error. > > - Fixed-in: https://github.com/curl/curl/commit/76f83f0db23846e254d940ec7 [...] Looking at the patch it seems the version check is using a string comparison instead of a proper numeric one on the version tuple (major, minor, revision, subrevison): if(strcmp(v, "1.2.0.4") >= 0) { Which, whilst I doubt we'll see such a zlib version any time soon if ever (though zlib-ng compat might get there a lot faster), would give an incorrect result for e.g. version "1.10.0.0". - Fay