Attention is currently required from: Nico Huber.
1 comment:
Patchset:
The issue we saw here was in the cgpt utility, for editing the RW_GPT region on some devices. For years (since 2015 when this code landed) it had this ugly code in attempt to squelch the stdout of flashrom:
int fd_flags = fcntl(1, F_GETFD);
// Close stdout on exec so that flashrom does not muck up cgpt's output.
if (0 != fcntl(1, F_SETFD, FD_CLOEXEC))
Warning("Can't stop flashrom from mucking up our output\n");
if (ForkExecL(temp_dir_template, FLASHROM_PATH, "-i", "RW_GPT:rw_gpt", "-r",
NULL) != 0) {
For years, this code was actually sending the output to a lock file that got opened before /dev/mtd0 (see https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/HEAD/big_lock.c in our fork of flashrom). But upon switching from Makefile to meson build systems, we dropped our config option for the lock file, and this was now being written to /dev/mtd0.
Quite honestly, this is one of the more fascinating bugs I've seen in my career... I would have never expected the kernel to re-use fd 0, 1, 2 for another random file if those got closed, but I guess it does.
Or maybe there's even something to fix in your libc.
Fixing this in glibc would probably break something :P
I actually doubt glibc would even want a "fix" which checks stdin, stdout, stderr are open before main. Sure, the library assumes it, but that's because POSIX says it can ;)
Anyway, this is a lot of a story to dump into the commit message. I think what I have there is detailed enough for the commit already ... if you think some detail here could be added to it, LMK.
To view, visit change 52215. To unsubscribe, or for help writing mail filters, visit settings.