[PATCH] resolv: use proper bound in __gai_freemem

[PATCH] resolv: use proper bound in __gai_freemem

[Peter Edwards]

__gai_freemem participates in the __libc_freeres mechanism to clean up
things at exit when requested by debugging/heap-checking tools such as
valgrind

The "pool" in gai_misc.c has valid data over the range [0, pool_size),
but the allocation stretches as far as pool_max_size. The elements
between pool_size and pool_max_size are uninitialized - so, use
pool_size as the iteration limit when free'ing data from pool, not
pool_max_size.
---
 resolv/gai_misc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/resolv/gai_misc.c b/resolv/gai_misc.c
index 9e3b1d29b7..0c0ae741f9 100644
--- a/resolv/gai_misc.c
+++ b/resolv/gai_misc.c
@@ -442,7 +442,7 @@ __gai_freemem (void)
 {
   size_t row;
 
-  for (row = 0; row < pool_max_size; ++row)
+  for (row = 0; row < pool_size; ++row)
     free (pool[row]);
 
   free (pool);
-- 
2.42.0.111.gd814540bb7

Re: [PATCH] resolv: use proper bound in __gai_freemem

[Florian Weimer]

* Peter Edwards via Libc-alpha:

> __gai_freemem participates in the __libc_freeres mechanism to clean up
> things at exit when requested by debugging/heap-checking tools such as
> valgrind
>
> The "pool" in gai_misc.c has valid data over the range [0, pool_size),
> but the allocation stretches as far as pool_max_size. The elements
> between pool_size and pool_max_size are uninitialized - so, use
> pool_size as the iteration limit when free'ing data from pool, not
> pool_max_size.
> ---
>  resolv/gai_misc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/resolv/gai_misc.c b/resolv/gai_misc.c
> index 9e3b1d29b7..0c0ae741f9 100644
> --- a/resolv/gai_misc.c
> +++ b/resolv/gai_misc.c
> @@ -442,7 +442,7 @@ __gai_freemem (void)
>  {
>    size_t row;
>  
> -  for (row = 0; row < pool_max_size; ++row)
> +  for (row = 0; row < pool_size; ++row)
>      free (pool[row]);
>  
>    free (pool);

Would you please re-post this with Signed-off-by:?  Patch itself looks
good.

Thanks,
Florian