3 ms·

These appear to be the relevant changes: 2022-07-30: https://github.com/madler/zlib/commit/eff308af425b67093bab25f80f1ae950166bece1 https://github.com/madler/z

These appear to be the relevant changes: 2022-07-30: https://github.com/madler/zlib/commit/eff308af425b67093bab25f80f1ae950166bece1 https://github.com/madler/zlib/commit/eff308af425b67093bab25... 2022-08-08: https://github.com/madler/zlib/commit/1eb7682f845ac9e9bf9ae35bbfb3bad5dacbd91d https://github.com/madler/zlib/commit/1eb7682f845ac9e9bf9ae3... The second commit definitely fixed a null pointer dereference, I am not sure if the CVE is referencing something else that was fixed by the first commit.

jomar 4y ago
Prior to 1.2.13 released a few days ago, neither of these commits was contained in a zlib release. The CVE exists in the state of the code prior to that first commit, and is fairly obvious when you read the explanation in the commit message. The first commit fixed the CVE but introduced a silly null pointer deference, which was quickly fixed by the second commit and never appeared in a release. Studying the code it's easy to convince yourself that the CVE description is correct and client code that does not use inflateGetHeader() is entirely immune to the CVE. Searching GitHub suggests that use of this function is uncommon, and certainly it's not used by any of the client code that I checked for potential vulnerability to this CVE. So all the client code that I checked was unaffected by this CVE. Hence IMHO this particular CVE is not really a big deal, because very little client software uses the somewhat obscure inflateGetHeader() API function. I suspect this is why the zlib maintainers didn't seem to be in a particular hurry to get this release out, after the CVE was made public in at least August or early September and they had already fixed it in early August. (Me, I became aware of it in early September, so the vulnerability was publicly disclosed at least by then.)

3 ms·

These appear to be the relevant changes: 2022-07-30: https://github.com/madler/zlib/commit/eff308af425b67093bab25f80f1ae950166bece1 https://github.com/madler/z

by omoikane 4y ago

jomar 4y ago
Prior to 1.2.13 released a few days ago, neither of these commits was contained in a zlib release. The CVE exists in the state of the code prior to that first commit, and is fairly obvious when you read the explanation in the commit message. The first commit fixed the CVE but introduced a silly null pointer deference, which was quickly fixed by the second commit and never appeared in a release. Studying the code it's easy to convince yourself that the CVE description is correct and client code that does not use inflateGetHeader() is entirely immune to the CVE. Searching GitHub suggests that use of this function is uncommon, and certainly it's not used by any of the client code that I checked for potential vulnerability to this CVE. So all the client code that I checked was unaffected by this CVE. Hence IMHO this particular CVE is not really a big deal, because very little client software uses the somewhat obscure inflateGetHeader() API function. I suspect this is why the zlib maintainers didn't seem to be in a particular hurry to get this release out, after the CVE was made public in at least August or early September and they had already fixed it in early August. (Me, I became aware of it in early September, so the vulnerability was publicly disclosed at least by then.)