bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
* heap-use-after-free in rpl_glob
@ 2020-01-17 15:50 Tim Rühsen
  2020-01-17 17:00 ` Bruno Haible
  0 siblings, 1 reply; 5+ messages in thread
From: Tim Rühsen @ 2020-01-17 15:50 UTC (permalink / raw)
  To: bug-gnulib


[-- Attachment #1.1.1: Type: text/plain, Size: 3498 bytes --]

Hi,

I recently updated wget2 to gnulib commit
a7903da07d3d18c23314aa0815adbb4058fd7cec.

The continuous fuzzer at OSS-Fuzz today reported an issue in rpl_glob.

To reproduce with attached C code (on Debian unstable here, same result
on Ubuntu 16.04.6 docker container with clang 10):

export CC=gcc
export CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address
-fsanitize-address-use-after-scope"
# ... build gnulib ...
$CC $CFLAGS -I. -Ilib glob_crash2.c -o glob_crash2 lib/.libs/libgnu.a
./glob_crash2

=================================================================
==1671628==ERROR: AddressSanitizer: heap-use-after-free on address
0x604000000013 at pc 0x55fa90a36ecd bp 0x7ffe68412980 sp 0x7ffe68412978
READ of size 44 at 0x604000000013 thread T0
    #0 0x55fa90a36ecc in rpl_glob /home/tim/src/wget2/lib/glob.c:868
    #1 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
    #2 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308
    #3 0x55fa90a332f9 in _start (/home/tim/src/wget2/glob_crash2+0x22f9)

0x604000000013 is located 3 bytes inside of 48-byte region
[0x604000000010,0x604000000040)
freed by thread T0 here:
    #0 0x7fdafb24c277 in __interceptor_free
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107277)
    #1 0x55fa90a36e31 in rpl_glob /home/tim/src/wget2/lib/glob.c:849
    #2 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
    #3 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308

previously allocated by thread T0 here:
    #0 0x7fdafb24c628 in malloc
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
    #1 0x55fa90a35311 in rpl_glob /home/tim/src/wget2/lib/glob.c:565
    #2 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
    #3 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-use-after-free
/home/tim/src/wget2/lib/glob.c:868 in rpl_glob
Shadow bytes around the buggy address:
  0x0c087fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c087fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c087fff8000: fa fa[fd]fd fd fd fd fd fa fa 00 00 00 00 00 01
  0x0c087fff8010: fa fa 00 00 00 00 00 01 fa fa 00 00 00 00 06 fa
  0x0c087fff8020: fa fa 00 00 00 00 06 fa fa fa 00 00 00 00 02 fa
  0x0c087fff8030: fa fa 00 00 00 00 02 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8040: fa fa 00 00 00 00 00 fa fa fa 00 00 00 00 00 fa
  0x0c087fff8050: fa fa 00 00 00 00 00 fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==1671628==ABORTING


Maybe someone who knows glob better than me could have a look. It seems
to be a regression.

Regards, Tim

[-- Attachment #1.1.2: glob_crash2.c --]
[-- Type: text/x-csrc, Size: 1443 bytes --]

/*
 * Created 17.01.2019 by Tim Rühsen
 *
 * Call glob() using data from fuzzer crash file
 *
 * Build and execute with instrumented gnulib (amend -I paths as needed):
 *
 * clang build (spills out WRITE heap buffer overflow)
 * export CC=clang-6.0
 * export CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address -fsanitize-address-use-after-scope"
 * $CC $CFLAGS -I. -Ilib glob_crash2.c -o glob_crash2 lib/.libs/libgnu.a
 * ./glob_crash2
 *
 * gcc build (spills out READ heap buffer overflow):
 * export CC=gcc
 * export CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address -fsanitize-address-use-after-scope"
 * $CC $CFLAGS -I. -Ilib glob_crash2.c -o glob_crash2 lib/.libs/libgnu.a
 * ./glob_crash2
 */

#include <stdio.h>
#include <glob.h>

int main(int argc, char **argv)
{
static const unsigned char data[] = {
  0x7e,0x6c,0x70,0x2f,0x83,0x6d,0x65,0x1d,0x75,0xef,0xcc,0xf0,0x74,0x1b,0x03,0x02,0x43,
  0x94,0x05,0x33,0x83,0x1a,0xd4,0x4c,0x9f,0xbb,0x62,0xe6,0xb5,0x99,0x75,0x9f,0x26,0x69,
  0xc0,0x49,0xb0,0x4b,0x38,0xe8,0x74,0x0c,0xc2,0xd1,0x81,0x46,0x77,0x2f,0x89,0xf1,0xc8,
  0x73,0xb3,0x8f,0xf7,0x60,0x63,0xba,0xa5,0x59,0xaa,0xd1,0xa8,0xfc,0xf8,0x20,0xd8,0x12,
  0x58,0x61,0x12,0xc6,0x21,0x5b,0xf5,0x93,0x5a,0x7c,0x79,0x34,0xa5,0x01, 0x00
};

	glob_t pglob = { .gl_pathc = 0 };
	if (glob((const char *) data, GLOB_MARK | GLOB_TILDE, NULL, &pglob) == 0)
		globfree(&pglob);

	return 0;
}

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: heap-use-after-free in rpl_glob
  2020-01-17 15:50 heap-use-after-free in rpl_glob Tim Rühsen
@ 2020-01-17 17:00 ` Bruno Haible
  2020-01-17 19:29   ` Tim Rühsen
  2020-01-17 19:52   ` Paul Eggert
  0 siblings, 2 replies; 5+ messages in thread
From: Bruno Haible @ 2020-01-17 17:00 UTC (permalink / raw)
  To: bug-gnulib; +Cc: Tim Rühsen, Paul Eggert

Hi Tim,

> The continuous fuzzer at OSS-Fuzz today reported an issue in rpl_glob.
> 
> To reproduce with attached C code (on Debian unstable here, same result
> on Ubuntu 16.04.6 docker container with clang 10):
> 
> export CC=gcc
> export CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address
> -fsanitize-address-use-after-scope"
> # ... build gnulib ...
> $CC $CFLAGS -I. -Ilib glob_crash2.c -o glob_crash2 lib/.libs/libgnu.a
> ./glob_crash2
> 
> =================================================================
> ==1671628==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x604000000013 at pc 0x55fa90a36ecd bp 0x7ffe68412980 sp 0x7ffe68412978
> READ of size 44 at 0x604000000013 thread T0
>     #0 0x55fa90a36ecc in rpl_glob /home/tim/src/wget2/lib/glob.c:868
>     #1 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
>     #2 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308
>     #3 0x55fa90a332f9 in _start (/home/tim/src/wget2/glob_crash2+0x22f9)
> 
> 0x604000000013 is located 3 bytes inside of 48-byte region
> [0x604000000010,0x604000000040)
> freed by thread T0 here:
>     #0 0x7fdafb24c277 in __interceptor_free
> (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107277)
>     #1 0x55fa90a36e31 in rpl_glob /home/tim/src/wget2/lib/glob.c:849
>     #2 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
>     #3 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308
> 
> previously allocated by thread T0 here:
>     #0 0x7fdafb24c628 in malloc
> (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
>     #1 0x55fa90a35311 in rpl_glob /home/tim/src/wget2/lib/glob.c:565
>     #2 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
>     #3 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308

I can't reproduce the crashes. But the line numbers (565, 849, 868)
from the output above are clearly indicating the problem:
  - end_name is part of dirname,
  - dirname is freed,
  - after dirname is freed, the code still accesses end_name.

Can you please test this patch?

Thank you very much for this report! I expect that the fix will also need
to go into glibc.


2020-01-17  Bruno Haible  <bruno@clisp.org>

	glob: Fix use-after-free bug.
	Reported by Tim Rühsen <tim.ruehsen@gmx.de> in
	<https://lists.gnu.org/archive/html/bug-gnulib/2020-01/msg00102.html>.
	* lib/glob.c (__glob): Delay freeing dirname until after the use of
	end_name.

diff --git a/lib/glob.c b/lib/glob.c
index a67cbb6..5b34939 100644
--- a/lib/glob.c
+++ b/lib/glob.c
@@ -843,10 +843,11 @@ __glob (const char *pattern, int flags, int (*errfunc) (const char *, int),
               {
                 size_t home_len = strlen (p->pw_dir);
                 size_t rest_len = end_name == NULL ? 0 : strlen (end_name);
+                /* dirname contains end_name; we can't free it now.  */
+                char *prev_dirname =
+                  (__glibc_unlikely (malloc_dirname) ? dirname : NULL);
                 char *d;
 
-                if (__glibc_unlikely (malloc_dirname))
-                  free (dirname);
                 malloc_dirname = 0;
 
                 if (glob_use_alloca (alloca_used, home_len + rest_len + 1))
@@ -868,6 +869,8 @@ __glob (const char *pattern, int flags, int (*errfunc) (const char *, int),
                   d = mempcpy (d, end_name, rest_len);
                 *d = '\0';
 
+                free (prev_dirname);
+
                 dirlen = home_len + rest_len;
                 dirname_modified = 1;
               }



^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: heap-use-after-free in rpl_glob
  2020-01-17 17:00 ` Bruno Haible
@ 2020-01-17 19:29   ` Tim Rühsen
  2020-01-17 19:52   ` Paul Eggert
  1 sibling, 0 replies; 5+ messages in thread
From: Tim Rühsen @ 2020-01-17 19:29 UTC (permalink / raw)
  To: Bruno Haible, bug-gnulib; +Cc: Paul Eggert


[-- Attachment #1.1: Type: text/plain, Size: 3878 bytes --]

Hi Bruno,

I can confirm that your patch doesn't trigger asan any more.

Thank you !

Regards, Tim

On 17.01.20 18:00, Bruno Haible wrote:
> Hi Tim,
> 
>> The continuous fuzzer at OSS-Fuzz today reported an issue in rpl_glob.
>>
>> To reproduce with attached C code (on Debian unstable here, same result
>> on Ubuntu 16.04.6 docker container with clang 10):
>>
>> export CC=gcc
>> export CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address
>> -fsanitize-address-use-after-scope"
>> # ... build gnulib ...
>> $CC $CFLAGS -I. -Ilib glob_crash2.c -o glob_crash2 lib/.libs/libgnu.a
>> ./glob_crash2
>>
>> =================================================================
>> ==1671628==ERROR: AddressSanitizer: heap-use-after-free on address
>> 0x604000000013 at pc 0x55fa90a36ecd bp 0x7ffe68412980 sp 0x7ffe68412978
>> READ of size 44 at 0x604000000013 thread T0
>>     #0 0x55fa90a36ecc in rpl_glob /home/tim/src/wget2/lib/glob.c:868
>>     #1 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
>>     #2 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308
>>     #3 0x55fa90a332f9 in _start (/home/tim/src/wget2/glob_crash2+0x22f9)
>>
>> 0x604000000013 is located 3 bytes inside of 48-byte region
>> [0x604000000010,0x604000000040)
>> freed by thread T0 here:
>>     #0 0x7fdafb24c277 in __interceptor_free
>> (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107277)
>>     #1 0x55fa90a36e31 in rpl_glob /home/tim/src/wget2/lib/glob.c:849
>>     #2 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
>>     #3 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308
>>
>> previously allocated by thread T0 here:
>>     #0 0x7fdafb24c628 in malloc
>> (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x107628)
>>     #1 0x55fa90a35311 in rpl_glob /home/tim/src/wget2/lib/glob.c:565
>>     #2 0x55fa90a334eb in main /home/tim/src/wget2/glob_crash2.c:35
>>     #3 0x7fdafafabbba in __libc_start_main ../csu/libc-start.c:308
> 
> I can't reproduce the crashes. But the line numbers (565, 849, 868)
> from the output above are clearly indicating the problem:
>   - end_name is part of dirname,
>   - dirname is freed,
>   - after dirname is freed, the code still accesses end_name.
> 
> Can you please test this patch?
> 
> Thank you very much for this report! I expect that the fix will also need
> to go into glibc.
> 
> 
> 2020-01-17  Bruno Haible  <bruno@clisp.org>
> 
> 	glob: Fix use-after-free bug.
> 	Reported by Tim Rühsen <tim.ruehsen@gmx.de> in
> 	<https://lists.gnu.org/archive/html/bug-gnulib/2020-01/msg00102.html>.
> 	* lib/glob.c (__glob): Delay freeing dirname until after the use of
> 	end_name.
> 
> diff --git a/lib/glob.c b/lib/glob.c
> index a67cbb6..5b34939 100644
> --- a/lib/glob.c
> +++ b/lib/glob.c
> @@ -843,10 +843,11 @@ __glob (const char *pattern, int flags, int (*errfunc) (const char *, int),
>                {
>                  size_t home_len = strlen (p->pw_dir);
>                  size_t rest_len = end_name == NULL ? 0 : strlen (end_name);
> +                /* dirname contains end_name; we can't free it now.  */
> +                char *prev_dirname =
> +                  (__glibc_unlikely (malloc_dirname) ? dirname : NULL);
>                  char *d;
>  
> -                if (__glibc_unlikely (malloc_dirname))
> -                  free (dirname);
>                  malloc_dirname = 0;
>  
>                  if (glob_use_alloca (alloca_used, home_len + rest_len + 1))
> @@ -868,6 +869,8 @@ __glob (const char *pattern, int flags, int (*errfunc) (const char *, int),
>                    d = mempcpy (d, end_name, rest_len);
>                  *d = '\0';
>  
> +                free (prev_dirname);
> +
>                  dirlen = home_len + rest_len;
>                  dirname_modified = 1;
>                }
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: heap-use-after-free in rpl_glob
  2020-01-17 17:00 ` Bruno Haible
  2020-01-17 19:29   ` Tim Rühsen
@ 2020-01-17 19:52   ` Paul Eggert
  2020-01-17 21:00     ` Bruno Haible
  1 sibling, 1 reply; 5+ messages in thread
From: Paul Eggert @ 2020-01-17 19:52 UTC (permalink / raw)
  To: Bruno Haible; +Cc: Tim Rühsen, bug-gnulib

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

On 1/17/20 9:00 AM, Bruno Haible wrote:
> Thank you very much for this report! I expect that the fix will also need
> to go into glibc.

Yes, thanks, I filed a bug report here:

https://sourceware.org/bugzilla/show_bug.cgi?id=25414

It seems that your patch is incomplete, as there's a memory leak in the 
unlikely case that the malloc call fails. Something like the attached 
patch instead, perhaps?

[-- Attachment #2: 0001-glob-Fix-use-after-free-bug.patch --]
[-- Type: text/x-patch, Size: 3328 bytes --]

From 8d5f7d7e43b8830acde4f82b93cc7b970d9ec435 Mon Sep 17 00:00:00 2001
From: Bruno Haible <bruno@clisp.org>
Date: Fri, 17 Jan 2020 11:51:26 -0800
Subject: [PATCH] glob: Fix use-after-free bug.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Reported by Tim Rühsen <tim.ruehsen@gmx.de> in
<https://lists.gnu.org/archive/html/bug-gnulib/2020-01/msg00102.html>.
* lib/glob.c (__glob): Delay freeing dirname until after the use of
end_name.
---
 ChangeLog  |  9 +++++++++
 lib/glob.c | 21 +++++++++++++--------
 2 files changed, 22 insertions(+), 8 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 643dba312..04b139a6a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2020-01-17  Bruno Haible  <bruno@clisp.org>
+	    Paul Eggert  <eggert@cs.ucla.edu>
+
+	glob: Fix use-after-free bug.
+	Reported by Tim Rühsen <tim.ruehsen@gmx.de> in
+	<https://lists.gnu.org/archive/html/bug-gnulib/2020-01/msg00102.html>.
+	* lib/glob.c (__glob): Delay freeing dirname until after the use of
+	end_name.
+
 2020-01-16  Siddhesh Poyarekar  <siddhesh@gotplt.org>
 
 	vcs-to-changelog: Fix parsing of fndecl without args.
diff --git a/lib/glob.c b/lib/glob.c
index a67cbb67e..e0928312a 100644
--- a/lib/glob.c
+++ b/lib/glob.c
@@ -843,24 +843,27 @@ __glob (const char *pattern, int flags, int (*errfunc) (const char *, int),
               {
                 size_t home_len = strlen (p->pw_dir);
                 size_t rest_len = end_name == NULL ? 0 : strlen (end_name);
+                /* dirname contains end_name; we can't free it now.  */
+                char *prev_dirname =
+                  (__glibc_unlikely (malloc_dirname) ? dirname : NULL);
                 char *d;
 
-                if (__glibc_unlikely (malloc_dirname))
-                  free (dirname);
-                malloc_dirname = 0;
-
                 if (glob_use_alloca (alloca_used, home_len + rest_len + 1))
-                  dirname = alloca_account (home_len + rest_len + 1,
-                                            alloca_used);
+                  {
+                    dirname = alloca_account (home_len + rest_len + 1,
+                                              alloca_used);
+                    malloc_dirname = 0;
+                  }
                 else
                   {
-                    dirname = malloc (home_len + rest_len + 1);
-                    if (dirname == NULL)
+                    char *new_dirname = malloc (home_len + rest_len + 1);
+                    if (new_dirname == NULL)
                       {
                         scratch_buffer_free (&pwtmpbuf);
                         retval = GLOB_NOSPACE;
                         goto out;
                       }
+                    dirname = new_dirname;
                     malloc_dirname = 1;
                   }
                 d = mempcpy (dirname, p->pw_dir, home_len);
@@ -868,6 +871,8 @@ __glob (const char *pattern, int flags, int (*errfunc) (const char *, int),
                   d = mempcpy (d, end_name, rest_len);
                 *d = '\0';
 
+                free (prev_dirname);
+
                 dirlen = home_len + rest_len;
                 dirname_modified = 1;
               }
-- 
2.24.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: heap-use-after-free in rpl_glob
  2020-01-17 19:52   ` Paul Eggert
@ 2020-01-17 21:00     ` Bruno Haible
  0 siblings, 0 replies; 5+ messages in thread
From: Bruno Haible @ 2020-01-17 21:00 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Tim Rühsen, bug-gnulib

[-- Attachment #1: Type: text/plain, Size: 512 bytes --]

Hi Paul,

> It seems that your patch is incomplete, as there's a memory leak in the 
> unlikely case that the malloc call fails.

Oops, indeed. Thanks for the review!

> Something like the attached patch instead, perhaps?

Hmm, this patch is freeing the same object through the variable 'dirname'
on one branch and through the variable 'previous_dirname' on the other
branch. A bit hard to understand, and thus likely to introduce more bugs
in the future, I would say. I prefer the attached one. Pushed.

Bruno


[-- Attachment #2: 0001-glob-Fix-use-after-free-bug.patch --]
[-- Type: text/x-patch, Size: 2740 bytes --]

From 717766da8926e36cf86015c4a49554baa854e8e6 Mon Sep 17 00:00:00 2001
From: Bruno Haible <bruno@clisp.org>
Date: Fri, 17 Jan 2020 21:56:01 +0100
Subject: [PATCH] glob: Fix use-after-free bug.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Reported by Tim Rühsen <tim.ruehsen@gmx.de> in
<https://lists.gnu.org/archive/html/bug-gnulib/2020-01/msg00102.html>.

* lib/glob.c (__glob): Delay freeing dirname until after the use of
end_name.
---
 ChangeLog  | 9 +++++++++
 lib/glob.c | 8 ++++++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 643dba3..4f4718a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2020-01-17  Bruno Haible  <bruno@clisp.org>
+            Paul Eggert  <eggert@cs.ucla.edu>
+
+	glob: Fix use-after-free bug.
+	Reported by Tim Rühsen <tim.ruehsen@gmx.de> in
+	<https://lists.gnu.org/archive/html/bug-gnulib/2020-01/msg00102.html>.
+	* lib/glob.c (__glob): Delay freeing dirname until after the use of
+	end_name.
+
 2020-01-16  Siddhesh Poyarekar  <siddhesh@gotplt.org>
 
 	vcs-to-changelog: Fix parsing of fndecl without args.
diff --git a/lib/glob.c b/lib/glob.c
index a67cbb6..add5d93 100644
--- a/lib/glob.c
+++ b/lib/glob.c
@@ -843,10 +843,11 @@ __glob (const char *pattern, int flags, int (*errfunc) (const char *, int),
               {
                 size_t home_len = strlen (p->pw_dir);
                 size_t rest_len = end_name == NULL ? 0 : strlen (end_name);
+                /* dirname contains end_name; we can't free it now.  */
+                char *prev_dirname =
+                  (__glibc_unlikely (malloc_dirname) ? dirname : NULL);
                 char *d;
 
-                if (__glibc_unlikely (malloc_dirname))
-                  free (dirname);
                 malloc_dirname = 0;
 
                 if (glob_use_alloca (alloca_used, home_len + rest_len + 1))
@@ -857,6 +858,7 @@ __glob (const char *pattern, int flags, int (*errfunc) (const char *, int),
                     dirname = malloc (home_len + rest_len + 1);
                     if (dirname == NULL)
                       {
+                        free (prev_dirname);
                         scratch_buffer_free (&pwtmpbuf);
                         retval = GLOB_NOSPACE;
                         goto out;
@@ -868,6 +870,8 @@ __glob (const char *pattern, int flags, int (*errfunc) (const char *, int),
                   d = mempcpy (d, end_name, rest_len);
                 *d = '\0';
 
+                free (prev_dirname);
+
                 dirlen = home_len + rest_len;
                 dirname_modified = 1;
               }
-- 
2.7.4


^ permalink raw reply related	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2020-01-17 21:00 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-17 15:50 heap-use-after-free in rpl_glob Tim Rühsen
2020-01-17 17:00 ` Bruno Haible
2020-01-17 19:29   ` Tim Rühsen
2020-01-17 19:52   ` Paul Eggert
2020-01-17 21:00     ` Bruno Haible

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).