[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wifNC+AAGVDN-B1gGNhKGqhnkoqWKCknAo6107oD0zGWA@mail.gmail.com>
Date: Wed, 20 Nov 2024 18:23:55 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Kees Cook <kees@...nel.org>, linux-kernel@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>,
Christophe JAILLET <christophe.jaillet@...adoo.fr>, Dan Carpenter <dan.carpenter@...aro.org>,
Nir Lichtman <nir@...htman.org>, syzbot+03e1af5c332f7e0eb84b@...kaller.appspotmail.com,
Tycho Andersen <tandersen@...flix.com>, Vegard Nossum <vegard.nossum@...cle.com>,
Zbigniew Jędrzejewski-Szmek <zbyszek@...waw.pl>
Subject: Re: [GIT PULL] execve updates for v6.13-rc1
On Wed, 20 Nov 2024 at 16:55, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> __set_task_comm cannot be called with bprm->file->f_dentry
> unconditionally.
No, no. Only for the "no path" case.
> The reason bprm->file->f_dentry.dentry was abandoned were concerns
> about breaking userspace.
There's no way it can break user space considering that right now
comm[] ends up being just garbage.
And I do *not* want to replace one garbage with a new one.
> > - get rid of fdpath that you made pointless by not using it for 'comm[]'
>
> Again binfmt_script still uses it.
Ahh, yeah, we can't just get rid of it.
But we're *not* adding a new complete garbage "copy random stuff badly
from user space" thing.
Linus
Powered by blists - more mailing lists