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.do...@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....@gnu.org > <bug-make-bounces+martin.dorey=hds....@gnu.org> on behalf of Haoxin Tu < > haoxi...@gmail.com> > *Sent:* Saturday, January 20, 2024 06:17 > *To:* Paul D. Smith <invalid.nore...@gnu.org> > *Cc:* Paul D. Smith <psm...@gnu.org>; bo...@kolpackov.net < > bo...@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.nore...@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/ >> >>
