* [PATCH] Avoid collect2 calling signal unsafe functions and/or unlink, with uninitialized memory (for gcc-9 branch)
@ 2020-02-21 16:07 Bernd Edlinger
2020-02-24 11:32 ` Richard Biener
0 siblings, 1 reply; 2+ messages in thread
From: Bernd Edlinger @ 2020-02-21 16:07 UTC (permalink / raw)
To: gcc-patches, Richard Biener, Jakub Jelinek
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
Hi,
this fixes the signal handler calling signal unsafe vfprintf and/or passing
uninitialized memory to unlink in signal handler.
This time it is the patch for the gcc-9 branch.
The difference to the gcc-8 branch is in tool_cleanup:
The variable that suppress the vfprintf is verbose = false;
not debug = false, to match the different logic in maybe_unlink.
Bootstrapped and reg-tested with x86_64-pc-linux-gnu.
Is it OK for the gcc-9 branch?
Thanks
Bernd.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Avoid-collect2-calling-signal-unsafe-functions-and-o.patch --]
[-- Type: text/x-patch; name="0001-Avoid-collect2-calling-signal-unsafe-functions-and-o.patch", Size: 1485 bytes --]
From d52ac2c0394f0432e183511f8a6d4f96b49f88a5 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger <bernd.edlinger@hotmail.de>
Date: Mon, 17 Feb 2020 17:40:07 +0100
Subject: [PATCH] Avoid collect2 calling signal unsafe functions and/or unlink
with uninitialized memory
2020-02-20 Bernd Edlinger <bernd.edlinger@hotmail.de>
* collect2.c (tool_cleanup): Avoid calling not signal-safe
functions.
(maybe_run_lto_and_relink): Avoid possible signal handler
access to unintialzed memory (lto_o_files).
---
gcc/collect2.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gcc/collect2.c b/gcc/collect2.c
index eb84f84..8f092e7 100644
--- a/gcc/collect2.c
+++ b/gcc/collect2.c
@@ -384,6 +384,10 @@ static void scan_prog_file (const char *, scanpass, scanfilter);
void
tool_cleanup (bool from_signal)
{
+ /* maybe_unlink may call notice, which is not signal safe. */
+ if (from_signal)
+ verbose = false;
+
if (c_file != 0 && c_file[0])
maybe_unlink (c_file);
@@ -743,7 +747,10 @@ maybe_run_lto_and_relink (char **lto_ld_argv, char **object_lst,
++num_files;
}
- lto_o_files = XNEWVEC (char *, num_files + 1);
+ /* signal handler may access uninitialized memory
+ and delete whatever it points to, if lto_o_files
+ is not allocated with calloc. */
+ lto_o_files = XCNEWVEC (char *, num_files + 1);
lto_o_files[num_files] = NULL;
start = XOBFINISH (&temporary_obstack, char *);
for (i = 0; i < num_files; ++i)
--
2.7.4
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] Avoid collect2 calling signal unsafe functions and/or unlink, with uninitialized memory (for gcc-9 branch)
2020-02-21 16:07 [PATCH] Avoid collect2 calling signal unsafe functions and/or unlink, with uninitialized memory (for gcc-9 branch) Bernd Edlinger
@ 2020-02-24 11:32 ` Richard Biener
0 siblings, 0 replies; 2+ messages in thread
From: Richard Biener @ 2020-02-24 11:32 UTC (permalink / raw)
To: Bernd Edlinger; +Cc: gcc-patches, Jakub Jelinek
On Fri, 21 Feb 2020, Bernd Edlinger wrote:
> Hi,
>
> this fixes the signal handler calling signal unsafe vfprintf and/or passing
> uninitialized memory to unlink in signal handler.
>
> This time it is the patch for the gcc-9 branch.
>
> The difference to the gcc-8 branch is in tool_cleanup:
> The variable that suppress the vfprintf is verbose = false;
> not debug = false, to match the different logic in maybe_unlink.
>
>
> Bootstrapped and reg-tested with x86_64-pc-linux-gnu.
> Is it OK for the gcc-9 branch?
OK.
Richard.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-02-24 11:32 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-21 16:07 [PATCH] Avoid collect2 calling signal unsafe functions and/or unlink, with uninitialized memory (for gcc-9 branch) Bernd Edlinger
2020-02-24 11:32 ` Richard Biener
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).