[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 25 Aug 2021 17:39:02 +0000
From: Travis Finkenauer <tmfink@...iper.net>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: Possible memory leak on getspnam / getspnam_r
> On Aug 24, 2021, at 4:14 PM, Jean Diogo <j@....com.br> wrote:
>
> Thus, although caching is mostly required for performance, maybe this
> (caching) should happen only on getspnam function but not on getspnam_r.
> That's because on getspnam_r the user wants to have control over this
> buffering, then the user has a way to clean up it's memory when this
> caching is not desired.
Per Hyrum's Law [1], there are users who expect this caching behavior. Such
users would hit a performance regression and be upset.
To control the caching behavior, there could be another function like
getspnam_r_with_cache() that takes an additional 'void **cache' parameter.
getspnam_r_with_cache() could update the pointer to point to a cache. If a user
wants to avoid caching, then the user could just pass NULL instead.
Alternatively, a new function cleanup_and_zeroize_caches() could added. A user
could call this after fork().
Of course, introducing a new function complicates the APIs and requires
developers to add them. Also, to support multiple versions of libraries,
developers would need to protect the call with an '#ifdef SUPPORTS_NEW_FUNCTION'.
-Travis
[1]: https://www.hyrumslaw.com/
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.
