Attention is currently required from: Nico Huber. Jack Rosenthal has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/52215 )
Change subject: linux_mtd: prevent corruption of flash when stdout/stderr is closed ......................................................................
Patch Set 1:
(1 comment)
Patchset:
PS1: 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... 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.