replace_fd() returns either a negative error number or the number of the new file descriptor. The current code misinterprets any positive file descriptor number as an error.
Only check for negative error numbers, so that __receive_sock() is called correctly for valid file descriptors.
Fixes: 173817151b15 ("fs: Expand __receive_fd() to accept existing fd") Fixes: 42eb0d54c08a ("fs: split receive_fd_replace from __receive_fd") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh thomas.weissschuh@linutronix.de --- Untested, it stuck out while reading the code. --- fs/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/file.c b/fs/file.c index 6d2275c3be9c6967d16c75d1b6521f9b58980926..56c3a045121d8f43a54cf05e6ce1962f896339ac 100644 --- a/fs/file.c +++ b/fs/file.c @@ -1387,7 +1387,7 @@ int receive_fd_replace(int new_fd, struct file *file, unsigned int o_flags) if (error) return error; error = replace_fd(new_fd, file, o_flags); - if (error) + if (error < 0) return error; __receive_sock(file); return new_fd;
--- base-commit: 89748acdf226fd1a8775ff6fa2703f8412b286c8 change-id: 20250801-fix-receive_fd_replace-7fdd5ce6532d
Best regards,
On Fri 01-08-25 09:38:38, Thomas Weißschuh wrote:
replace_fd() returns either a negative error number or the number of the new file descriptor. The current code misinterprets any positive file descriptor number as an error.
Only check for negative error numbers, so that __receive_sock() is called correctly for valid file descriptors.
Fixes: 173817151b15 ("fs: Expand __receive_fd() to accept existing fd") Fixes: 42eb0d54c08a ("fs: split receive_fd_replace from __receive_fd") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh thomas.weissschuh@linutronix.de
Indeed. I'm wondering how come nobody noticed... Feel free to add:
Reviewed-by: Jan Kara jack@suse.cz
Honza
Untested, it stuck out while reading the code.
fs/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/file.c b/fs/file.c index 6d2275c3be9c6967d16c75d1b6521f9b58980926..56c3a045121d8f43a54cf05e6ce1962f896339ac 100644 --- a/fs/file.c +++ b/fs/file.c @@ -1387,7 +1387,7 @@ int receive_fd_replace(int new_fd, struct file *file, unsigned int o_flags) if (error) return error; error = replace_fd(new_fd, file, o_flags);
- if (error)
- if (error < 0) return error; __receive_sock(file); return new_fd;
base-commit: 89748acdf226fd1a8775ff6fa2703f8412b286c8 change-id: 20250801-fix-receive_fd_replace-7fdd5ce6532d
Best regards,
Thomas Weißschuh thomas.weissschuh@linutronix.de
On Fri, Aug 01, 2025 at 12:48:09PM +0200, Jan Kara wrote:
On Fri 01-08-25 09:38:38, Thomas Weißschuh wrote:
replace_fd() returns either a negative error number or the number of the new file descriptor. The current code misinterprets any positive file descriptor number as an error.
Only check for negative error numbers, so that __receive_sock() is called correctly for valid file descriptors.
Fixes: 173817151b15 ("fs: Expand __receive_fd() to accept existing fd") Fixes: 42eb0d54c08a ("fs: split receive_fd_replace from __receive_fd") Cc: stable@vger.kernel.org Signed-off-by: Thomas Weißschuh thomas.weissschuh@linutronix.de
Indeed. I'm wondering how come nobody noticed...
One word: seccomp. Considering the background amount of bogus userland behaviour coming with it, I wouldn't expect a... vigorous test coverage for that one ;-/
It's definitely a bug that needs fixing, but I'm not sure this is the right way to fix it.
Look: replace_fd(fd, file, flags) returns fd on success and -E... on failure. Not a single user cares which non-negative value had been returned. What's more, "returns fd on success" is a side effect of using do_dup2() and being lazy about it.
And the entire thing is not on any hot paths. So I suspect that a better fix would be
err = do_dup2(files, file, fd, flags); if (err < 0) return err; return 0;
in replace_fd() in place of return do_dup2(files, file, fd, flags);
so we don't invite more surprises like that.
linux-stable-mirror@lists.linaro.org
-
Al Viro -
Jan Kara -
Thomas Weißschuh