bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug #64551] Possible null pointer dereference on the function get_b


From: Haoxin Tu
Subject: Re: [bug #64551] Possible null pointer dereference on the function get_buffer
Date: Sat, 20 Jan 2024 23:37:59 +0800

Hi Martin,

Thanks for your speedy reply and clarifications.

But I don't understand why the second invocation of `xrealloc` can not return zero, I apologize for any imprecise information I provided in the previous emails. 

From my understanding, once the second the `xrealloc` is invocated, there is a possibility that the `result` (https://github.com/mirror/make/blob/4.2/misc.c#L247) can return zero (from either `realloc` or `malloc`, just like the first invocation of `xrealloc`). Later, the `OUT_OF_MEM` function will be invocated again, and then the function `get_buffer`. In the following execution inside the function `get_buffer`, no `xrealloc` will be called as the condition `need > fmtbuf.size` (https://github.com/mirror/make/blob/4.2/output.c#L599) is false (the global static value `fmtbuf.size`, defined in https://github.com/mirror/make/blob/4.2/output.c#L593, was increased after the previous innovation of `get_buffer`), and then the execution of `fmtbuf.buffer[need-1] = '\0';` (https://github.com/mirror/make/blob/4.2/output.c#L605) leads to the null pointer dereference. Btw, I am sorry I don't see the recursive execution in this case (the link you provided seems old and I don't see such implementation in the version of make-4.2).

Please kindly let me know if I misunderstand something. Thank you so much for your time again!

Best regards,
Haoxin

Martin Dorey <Martin.Dorey@hitachivantara.com> 于2024年1月20日周六 22:43写道:
  • once the second invocation of `xrealloc` ... returns zero

But it doesn't, it just recurses, calls get_buffer again, again likely fails and recurses still further until the stack is blown.  Or it did until https://git.savannah.gnu.org/cgit/make.git/commit/?id=68be4f74fce91b76e5915449268d6b5eb687aab9.


From: bug-make-bounces+martin.dorey=hds.com@gnu.org <bug-make-bounces+martin.dorey=hds.com@gnu.org> on behalf of Haoxin Tu <haoxintu@gmail.com>
Sent: Saturday, January 20, 2024 06:17
To: Paul D. Smith <INVALID.NOREPLY@gnu.org>
Cc: Paul D. Smith <psmith@gnu.org>; boris@kolpackov.net <boris@kolpackov.net>; bug-make@gnu.org <bug-make@gnu.org>
Subject: Re: [bug #64551] Possible null pointer dereference on the function get_buffer
 
***** EXTERNAL EMAIL *****
Hi,

Thank you so much for your time and reply.

We understand that the entire point of `xrealloc` is never returning 0 to client users/developers who use this function. However, the issue we reported here happens when the `xrealloc` internally handles the returned 0 from `realloc` or `malloc` functions. 

In general, the key point is that the function `OUT_OF_MEM()` (invoked when the `result` gets a 0 in the implementation of `xrealloc`) does not immediately terminate the program execution, and the function `OUT_OF_MEM()` will continue to allocate buffers via `xrealloc` for printing purposes in the following and then terminate. Specifically, the continuous execution of function `OUT_OF_MEM()` calls the `xrealloc` again through the `get_buffer` function (`OUT_OF_MEM()` is a macro definition that will call the function `fatal`, which finally invocates the function `get_buffer`). As we mentioned in the initial report, once the second invocation of `xrealloc` (i.e., the one called inside `OUT_OF_MEM()`) returns zero and calls `OUT_OF_MEM()` again, a null pointer dereference is occurred in `fmtbuf.buffer[need-1] = '\0';` in the function `get_buffer`.

Please kindly check my explanation above and correct me if I am wrong. Thank you so much again and looking forward to hearing from you back again.


Best regards,
Haoxin

Paul D. Smith <INVALID.NOREPLY@gnu.org> 于2024年1月7日周日 01:49写道:
Update of bug#64551 (group make):

                  Status:                    None => Duplicate             
             Assigned to:                    None => psmith                 
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:

I don't see how the "second" xrealloc() would return 0; the entire point of
xrealloc is that it never returns 0.

However, I can see where the behavior of the code might lead to an infinite
loop.

This issue was already addressed in GNU Make 4.3 via bug #13651
The version you're testing (4.2) was released in 2016.

It's certainly helpful to check for errors in tools like GNU Make but please
check either the most recent published version or, even better, the current
Git HEAD version.

Thanks!


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64551>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]