From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id C92D1384240C for ; Thu, 16 Jul 2020 13:55:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C92D1384240C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 1A87F3000E8D; Thu, 16 Jul 2020 15:55:40 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id B7D474000DB9; Thu, 16 Jul 2020 15:55:40 +0200 (CEST) Message-ID: <31c7983432368f62b6d8a7c5e0f395770de3ac2e.camel@klomp.org> Subject: Re: call to =?UTF-8?Q?=E2=80=98fprintf=E2=80=99?= from within signal handler [CWE-479] From: Mark Wielaard To: noloader@gmail.com, bzip2-devel@sourceware.org Date: Thu, 16 Jul 2020 15:55:40 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: bzip2-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bzip2-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2020 13:55:44 -0000 Hi Jeffrey, On Thu, 2020-07-16 at 04:49 -0400, Jeffrey Walton via Bzip2-devel wrote: > I'm testing a build with the GCC 10 analyzer. Add -fanalyzer to > CFLAGS. If you need GCC 10, then you can find it on Fedora 32. The GCC -fanalyzer is indeed awesome! > The Analyzer is producing a finding: >=20 > bzip2.c:677:4: warning: call to =E2=80=98fprintf=E2=80=99 from within sig= nal handler > [CWE-479] [-Wanalyzer-unsafe-call-within-signal-handler] > 677 | fprintf ( > | ^~~~~~~~~ > 678 | stderr, > | ~~~~~~~ > 679 | "\tInput file =3D %s, output file =3D %s\n", > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 680 | inName, outName > | ~~~~~~~~~~~~~~~ > 681 | ); >=20 > There are two additional findings that are similar. That should already have been fixed in git: commit 8ca1faa31f396d94ab927b257f3a05236c84e330 Author: Mark Wielaard Date: Sun May 17 20:02:31 2020 +0200 Don't call unsafe functions from SIGSEGV/SIGBUS signal handler. =20 GCC10 -fanalyzer notices that we try to call functions that are not signal safe from our fatal signal handler: =20 bzip2.c: In function =E2=80=98mySIGSEGVorSIGBUScatcher=E2=80=99: bzip2.c:819:7: warning: call to =E2=80=98fprintf=E2=80=99 from within s= ignal handler [CWE-479] [-Wanalyzer-unsafe-call-within-signal-handler] =20 It also notices we then call showFileNames and cleanupAndFail which also call possibly not signal safe functions. =20 Just write out the error message directly to STDERR and exit without trying to clean up any files.