tmpfile() failure results in crash

[Krzesimir Nowak]

Hi,

I was recently doing some toolchain updates in Flatcar and one of the updated 
packages was make (to version 4.3). At some point it's being run inside some 
weird environment (inside docker container, then chroot created by Gentoo's 
catalyst) to build binutils so that caused tmpfile() to fail with EPERM (?!).

Make is starting to output (output_start()), finds out it's not set up, so 
makes sets it up. During this operation make invokes tmpfile() which fails. As 
a reaction, make calls pfatal_with_name() that starts the output. But since 
output is not yet set up, make sets it up. During that operation make invokes 
tmpfile()… and so on. Basically the backtrace looked like:

…
#115789 output_start () at src/output.c:514
#115790 0x000055d8dae57e64 in outputs (is_err=1, msg=0x55d8db8512d0 "make[1]: 
*** tmpfile: Permission denied.  Stop.\n") at src/output.c:530
#115791 0x000055d8dae580ae in fatal (flocp=flocp@entry=0x0, len=72, 
fmt=fmt@entry=0x55d8dae68983 "%s: %s") at src/output.c:647
#115792 0x000055d8dae57c8b in pfatal_with_name (name=name@entry=0x55d8dae6add9 
"tmpfile") at src/output.c:667
#115793 0x000055d8dae57cf2 in output_tmpfd () at src/output.c:289
#115794 0x000055d8dae57dbc in setup_tmpfile (out=0x55d8db970680) at 
src/output.c:320
#115795 output_start () at src/output.c:514
#115796 0x000055d8dae57e64 in outputs (is_err=1, msg=0x55d8db8512d0 "make[1]: 
*** tmpfile: Permission denied.  Stop.\n") at src/output.c:530
#115797 0x000055d8dae580ae in fatal (flocp=flocp@entry=0x0, len=72, 
fmt=fmt@entry=0x55d8dae68983 "%s: %s") at src/output.c:647
#115798 0x000055d8dae57c8b in pfatal_with_name (name=name@entry=0x55d8dae6add9 
"tmpfile") at src/output.c:667
#115799 0x000055d8dae57cf2 in output_tmpfd () at src/output.c:289
#115800 0x000055d8dae57dbc in setup_tmpfile (out=0x55d8db970680) at 
src/output.c:320
#115801 output_start () at src/output.c:514
#115802 0x000055d8dae52be7 in start_job_command 
(child=child@entry=0x55d8db970670) at src/job.c:1391
#115803 0x000055d8dae539e3 in start_waiting_job (c=c@entry=0x55d8db970670) at 
src/job.c:1634
#115804 0x000055d8dae54280 in new_job (file=<optimized out>) at src/job.c:1912
#115805 0x000055d8dae5fd44 in remake_file (file=0x55d8db8d9100) at 
src/remake.c:1234
#115806 update_file_1 (depth=<optimized out>, file=0x55d8db8d9100) at 
src/remake.c:835
…
#115819 update_file (file=file@entry=0x55d8db7e9810, depth=<optimized out>) at 
src/remake.c:336
#115820 0x000055d8dae60774 in update_goal_chain (goaldeps=<optimized out>) at 
src/remake.c:151
#115821 0x000055d8dae43d11 in main (argc=<optimized out>, argv=<optimized out>, 
envp=<optimized out>) at src/main.c:2589

I suspect that this is related to the fact the binutils ebuild passes 
--output-sync=line to the make invocation, but I'm probably wrong.

Anyway, my knee-jerk reaction was to patch out the pfatal_with_name invocations 
as follows:

BEGIN PATCH
diff -u -r make-4.3/src/output.c make-4.3-fix/src/output.c
--- make-4.3/src/output.c       2020-01-03 07:11:27.000000000 -0000
+++ make-4.3-fix/src/output.c   2022-08-17 07:35:01.473471281 -0000
@@ -286,15 +286,16 @@
   FILE *tfile = tmpfile ();
 
   if (! tfile)
-    pfatal_with_name ("tmpfile");
+    return -1;
 
   /* Create a duplicate so we can close the stream.  */
   fd = dup (fileno (tfile));
-  if (fd < 0)
-    pfatal_with_name ("dup");
 
   fclose (tfile);
 
+  if (fd < 0)
+    return -1;
+
   set_append_mode (fd);
 
   umask (mask);
END PATCH

My reasoning was that the only invoker of the patched function (output_tmpfd()) 
is setup_tmpfile() and it already has a code handling the failure coming from 
output_tmpfd(), so let output_tmpfd() to return -1 instead of aborting with 
pfatal_with_name().