summaryrefslogtreecommitdiffstats
path: root/fs/binfmt_elf.c
diff options
context:
space:
mode:
authorChristian Brauner <brauner@kernel.org>2024-11-27 12:45:02 +0100
committerChristian Brauner <brauner@kernel.org>2024-11-27 12:51:30 +0100
commit3b832035387ff508fdcf0fba66701afc78f79e3d (patch)
tree4369eadb61eb63f75302ddc5ad9bc36794f1a0e0 /fs/binfmt_elf.c
parentMerge tag 'for-6.13/dm-changes' of git://git.kernel.org/pub/scm/linux/kernel/... (diff)
downloadlinux-3b832035387ff508fdcf0fba66701afc78f79e3d.tar.xz
linux-3b832035387ff508fdcf0fba66701afc78f79e3d.zip
Revert "fs: don't block i_writecount during exec"
This reverts commit 2a010c41285345da60cece35575b4e0af7e7bf44. Rui Ueyama <rui314@gmail.com> writes: > I'm the creator and the maintainer of the mold linker > (https://github.com/rui314/mold). Recently, we discovered that mold > started causing process crashes in certain situations due to a change > in the Linux kernel. Here are the details: > > - In general, overwriting an existing file is much faster than > creating an empty file and writing to it on Linux, so mold attempts to > reuse an existing executable file if it exists. > > - If a program is running, opening the executable file for writing > previously failed with ETXTBSY. If that happens, mold falls back to > creating a new file. > > - However, the Linux kernel recently changed the behavior so that > writing to an executable file is now always permitted > (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a010c412853). > > That caused mold to write to an executable file even if there's a > process running that file. Since changes to mmap'ed files are > immediately visible to other processes, any processes running that > file would almost certainly crash in a very mysterious way. > Identifying the cause of these random crashes took us a few days. > > Rejecting writes to an executable file that is currently running is a > well-known behavior, and Linux had operated that way for a very long > time. So, I don’t believe relying on this behavior was our mistake; > rather, I see this as a regression in the Linux kernel. Quoting myself from commit 2a010c412853 ("fs: don't block i_writecount during exec") > Yes, someone in userspace could potentially be relying on this. It's not > completely out of the realm of possibility but let's find out if that's > actually the case and not guess. It seems we found out that someone is relying on this obscure behavior. So revert the change. Link: https://github.com/rui314/mold/issues/1361 Link: https://lore.kernel.org/r/4a2bc207-76be-4715-8e12-7fc45a76a125@leemhuis.info Cc: <stable@vger.kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
Diffstat (limited to 'fs/binfmt_elf.c')
-rw-r--r--fs/binfmt_elf.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 3039a6b7aba4..106f0e8af177 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1257,6 +1257,7 @@ out_free_interp:
}
reloc_func_desc = interp_load_addr;
+ allow_write_access(interpreter);
fput(interpreter);
kfree(interp_elf_ex);
@@ -1353,6 +1354,7 @@ out_free_dentry:
kfree(interp_elf_ex);
kfree(interp_elf_phdata);
out_free_file:
+ allow_write_access(interpreter);
if (interpreter)
fput(interpreter);
out_free_ph: