Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 22 Jun 2023 08:50:42 -0400
From: Demi Marie Obenour <>
To: Steve Grubb <>,
Subject: Re: CVE-2023-31975: memory leak in yasm

On Wed, Jun 21, 2023 at 09:53:54PM -0400, Steve Grubb 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
> > > > .
> > > 
> > > 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.

glibc exports a function for this exact purpose, and sanitizers call it
precisely to avoid false leak reports.  Static analyzers can also be
told to act as if that function is called.
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

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.