Re: CVE-2023-31975: memory leak in yasm

[Jeffrey Walton <noloader () gmail com>]

On Wed, Jun 21, 2023 at 9:55 PM Steve Grubb <sgrubb () redhat com> wrote:
> On Wednesday, June 21, 2023 5:54:57 PM EDT Demi Marie Obenour wrote:
> > On Thu, Jun 22, 2023 at 01:44:04AM +1000, Dave Horsfall wrote:
> > > On Wed, 21 Jun 2023, Jeffrey Walton wrote:
> > > > Memory leaks on exit are par for the course in GNU software per
> > > > https://www.gnu.org/prep/standards/standards.html#Memory-Usage .
> > >
> > > Don't bother with this, don't bother with that, etc...  Call me
> > > old-school (which I am), but I cannot abide sloppy programming[*].
> >
> > Memory leaks on exit are a _good_ thing in general.  There is absolutely
> > zero point in calling free() if the program is about to exit — the OS
> > will do a better job of freeing resources than the program itself ever
> > could.
>
> Sure, but how can static analysis or address sanitizers tell the difference
> between something created and leaked on the error path, vs something that
> mattered during the life of the program? Meaning something leaks in an event
> loop and slowly accumulates leakage. Nothing gives you a free pass but the OS
> when analyzing leaks. Mundane leaks need cleaning up so you can find the real
> leaks that matter.

Right. And shared objects are even worse. The test program exits,
memory is cleaned up by the OS, so who cares, right?

Just ask the OpenJDK developers who had to contend with the OpenSSL
memory leaks that exhausted all memory on Android devices. The
accumulated leaks literally used up all memory. That's because shared
objects are loaded/unloaded hundreds of times over the life of a
program on Android.

Another offender from GNU is ncurses. It leaks like a sieve, too.
Ncurses makes it nearly impossible to test GNU programs because
ncurses masks real problems (in itself and the program). And it causes
resource exhaustion on mobile devices, too.

It's very unfortunate the world has to lower its standards to that of
GNU software.

Jeff