[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <515f855d-cb54-4eb4-912f-a88454e6a26b@geeklan.co.uk>
Date: Tue, 17 Feb 2026 23:57:49 +0000
From: Sevan Janiyan <venture37@...klan.co.uk>
To: oss-security@...ts.openwall.com
Subject: Re: Re: zlib security audit by 7asecurity
On 17/02/2026 21:21, Simon Josefsson wrote:
> Great to see audits of widely used code! Gzip next?
>
> Sam James<sam@...too.org> writes:
>
>> * ZLB-01-001 WP2: Heap Buffer Overflow via Legacy gzprintf Implementation (High)
> That vulnerability seems to require that zlib was built with
> -DNO_vsnprintf -DNO_snprintf, targetting a system lacking 'snprintf'.
>
> Does anyone know of a real-world environment using that configuration?
Greetings from 2005, packaging for OS X 10.4 with GCC 4.0 which defaults
to C89.
From gzguts.h:
# elif !defined(__STDC_VERSION__) || __STDC_VERSION__-0 < 199901L
/* Otherwise if C89/90, assume no C99 snprintf() or vsnprintf() */
# ifndef NO_snprintf
# define NO_snprintf
# endif
# ifndef NO_vsnprintf
# define NO_vsnprintf
# endif
# endif
#endif
https://github.com/madler/zlib/blob/da607da739fa6047df13e66a2af6b8bec7c2a498/gzguts.h#L95C1-L104C7
I could set -std=gnu99 but then it's not going to be a quiet drop-in
upgrade for all the exist packages built.
Was actually thinking that what happens during configure and the build
are completely different. configure "detects" the presence of
vsnprintf() by the compiler not making any noise, but things are handled
separately in gzguts.h which until you dig in are left wondering why is
it complaining about the lack of vsnprintf() when the configure stage
was happy). Will raise a ticket for that.
Sincerely,
Sevan
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
