[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Memleak in glob()
From: |
Tim Rühsen |
Subject: |
Re: Memleak in glob() |
Date: |
Sun, 02 Jul 2017 17:20:45 +0200 |
User-agent: |
KMail/5.2.3 (Linux/4.9.0-3-amd64; KDE/5.28.0; x86_64; ; ) |
Hi Bruno,
On Sonntag, 2. Juli 2017 14:00:27 CEST Bruno Haible wrote:
> > In code that I am responsible for,
> > especially complex code as glob(), I also set pointers to NULL after
> > free() or when assigning/moving to another variable.
>
> Such a coding style does not help. What you need is to reduce the
> complexity, either by introducing inline functions, or by at least reducing
> the scope of the variables in the big function.
>
> The only situations where "set pointers to NULL after free()" is useful are:
> - when you're dealing with global variables or heap-allocated struct
> members (or class members in C++), or
> - when there is a (conservative) garbage collector around.
What I meant (in general) is the avoidance of 'use after free' [1] issues.
Not leaving around dangling pointers avoids this, so erroneous code is more
unlikely to become a security issue (it's just a segmentation fault then).
In glob() the code is not resetting the dirname memory policy flag when
'dirname' is stuffed into another variable. No doing so can easily lead to
either a double free and/or a use after free.
Regards, Tim
[1] https://www.owasp.org/index.php/Using_freed_memory
signature.asc
Description: This is a digitally signed message part.
Re: Memleak in glob(), Paul Eggert, 2017/07/02