]> git.infradead.org Git - nvme.git/commit
uselib: remove use of __FMODE_EXEC
authorLinus Torvalds <torvalds@linux-foundation.org>
Wed, 24 Jan 2024 21:12:20 +0000 (13:12 -0800)
committerLinus Torvalds <torvalds@linux-foundation.org>
Wed, 24 Jan 2024 21:12:20 +0000 (13:12 -0800)
commit3eab830189d94f0f80f34cbff609b5bb54002679
tree33f882ebb39cbd0ca0803945e8245fdfe8d7d604
parent443b349019f2d9461b23213a4308f9cf72e41c5e
uselib: remove use of __FMODE_EXEC

Jann Horn points out that uselib() really shouldn't trigger the new
FMODE_EXEC logic introduced by commit 4759ff71f23e ("exec: __FMODE_EXEC
instead of in_execve for LSMs").

In fact, it shouldn't even have ever triggered the old pre-existing
logic for __FMODE_EXEC (like the NFS code that makes executables not
need read permissions).  Unlike a real execve(), that can work even with
files that are purely executable by the user (not readable), uselib()
has that MAY_READ requirement becasue it's really just a convenience
wrapper around mmap() for legacy shared libraries.

The whole FMODE_EXEC bit was originally introduced by commit
b500531e6f5f ("[PATCH] Introduce FMODE_EXEC file flag"), primarily to
give ETXTBUSY error returns for distributed filesystems.

It has since grown a few other warts (like that NFS thing), but there
really isn't any reason to use it for uselib(), and now that we are
trying to use it to replace the horrid 'tsk->in_execve' flag, it's
actively wrong.

Of course, as Jann Horn also points out, nobody should be enabling
CONFIG_USELIB in the first place in this day and age, but that's a
different discussion entirely.

Reported-by: Jann Horn <jannh@google.com>
Fixes: 4759ff71f23e ("exec: __FMODE_EXEC instead of in_execve for LSMs")
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/exec.c