From: Oleg Nesterov <oleg@redhat.com>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>,
Kees Cook <kees@kernel.org>,
jack@suse.cz, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
syzkaller-bugs@googlegroups.com,
syzbot <syzbot+1c486d0b62032c82a968@syzkaller.appspotmail.com>
Subject: Re: [syzbot] [fs?] [mm?] KCSAN: data-race in bprm_execve / copy_fs (4)
Date: Sun, 23 Mar 2025 19:14:21 +0100 [thread overview]
Message-ID: <20250323181419.GA14883@redhat.com> (raw)
In-Reply-To: <20250322185007.GI2023217@ZenIV>
On 03/22, Al Viro wrote:
>
> On Sat, Mar 22, 2025 at 04:55:39PM +0100, Oleg Nesterov wrote:
>
> > And this means that we just need to ensure that ->in_exec is cleared
> > before this mutex is dropped, no? Something like below?
>
> Probably should work, but I wonder if it would be cleaner to have
> ->in_exec replaced with pointer to task_struct responsible. Not
> "somebody with that fs_struct for ->fs is trying to do execve(),
> has verified that nothing outside of their threads is using this
> and had been holding ->signal->cred_guard_mutex ever since then",
> but "this is the thread that..."
perhaps... or something else to make this "not immediately obvious"
fs->in_exec more clear.
But I guess we need something simple for -stable, so will you agree
with this fix for now? Apart from changelog/comments.
retval = de_thread(me);
+ current->fs->in_exec = 0;
if (retval)
current->fs->in_exec = 0;
is correct but looks confusing. See "V2" below, it clears fs->in_exec
after the "if (retval)" check.
syzbot says:
Unfortunately, I don't have any reproducer for this issue yet.
so I guess "#syz test: " is pointless right now...
Oleg.
---
diff --git a/fs/exec.c b/fs/exec.c
index 506cd411f4ac..02e8824fc9cd 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1236,6 +1236,7 @@ int begin_new_exec(struct linux_binprm * bprm)
if (retval)
goto out;
+ current->fs->in_exec = 0;
/*
* Cancel any io_uring activity across execve
*/
@@ -1497,6 +1498,8 @@ static void free_bprm(struct linux_binprm *bprm)
}
free_arg_pages(bprm);
if (bprm->cred) {
+ // for the case exec fails before de_thread()
+ current->fs->in_exec = 0;
mutex_unlock(¤t->signal->cred_guard_mutex);
abort_creds(bprm->cred);
}
@@ -1862,7 +1865,6 @@ static int bprm_execve(struct linux_binprm *bprm)
sched_mm_cid_after_execve(current);
/* execve succeeded */
- current->fs->in_exec = 0;
current->in_execve = 0;
rseq_execve(current);
user_events_execve(current);
@@ -1881,7 +1883,6 @@ static int bprm_execve(struct linux_binprm *bprm)
force_fatal_sig(SIGSEGV);
sched_mm_cid_after_execve(current);
- current->fs->in_exec = 0;
current->in_execve = 0;
return retval;
next prev parent reply other threads:[~2025-03-23 18:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-20 19:09 [syzbot] [fs?] [mm?] KCSAN: data-race in bprm_execve / copy_fs (4) syzbot
2025-03-20 20:09 ` Kees Cook
2025-03-21 1:44 ` Al Viro
2025-03-21 8:10 ` Kees Cook
2025-03-21 8:49 ` Christian Brauner
2025-03-21 8:45 ` Christian Brauner
2025-03-22 1:00 ` Al Viro
2025-03-22 6:26 ` Kees Cook
2025-03-22 10:15 ` Mateusz Guzik
2025-03-22 10:28 ` Christian Brauner
2025-03-22 10:23 ` Christian Brauner
2025-03-22 15:55 ` Oleg Nesterov
2025-03-22 18:50 ` Al Viro
2025-03-23 18:14 ` Oleg Nesterov [this message]
2025-03-23 20:57 ` Christian Brauner
2025-03-24 16:00 ` [PATCH] exec: fix the racy usage of fs_struct->in_exec Oleg Nesterov
2025-03-24 17:01 ` Mateusz Guzik
2025-03-24 18:27 ` Oleg Nesterov
2025-03-24 18:37 ` Oleg Nesterov
2025-03-24 22:24 ` Mateusz Guzik
2025-03-25 10:09 ` Oleg Nesterov
2025-03-25 11:01 ` Mateusz Guzik
2025-03-25 13:21 ` Oleg Nesterov
2025-03-25 13:30 ` Christian Brauner
2025-03-25 14:15 ` Mateusz Guzik
2025-03-25 14:46 ` Christian Brauner
2025-03-25 18:40 ` Kees Cook
2025-04-29 15:49 ` Oleg Nesterov
2025-04-29 16:57 ` Kees Cook
2025-04-29 17:12 ` Mateusz Guzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250323181419.GA14883@redhat.com \
--to=oleg@redhat.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=kees@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=syzbot+1c486d0b62032c82a968@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.