Re: [MAINTAINERS SUMMIT] Scaling our security process

[Sasha Levin <sashal@kernel.org>]

On Mon, Jul 27, 2026 at 10:08:48AM -0700, Linus Torvalds wrote:
>On Mon, 27 Jul 2026 at 07:37, Jiri Kosina <jikos@kernel.org> wrote:
>>
>> Well, linux-distros@ is still there, and is used to coordinate security
>> fixes in exactly this way consistently for vast majority of all the
>> relevant projects, pretty much except for the kernel. With my distro hat
>> on, I'd add "unfortunately".
>
>I refuse to have anything to do with linux-distros.
>
>They have a hard mandatory disclosure policy, which I think is
>completely unacceptable. It means that if you send actual exploits to
>the channel those exploits will be made public too. There is
>absolutely no value in that, and it seems completely crazy to me.
>
>Yet exploit code - or at least a PoC - are hugely useful to
>developers. So you do want to have people who figure out some security
>issue - or any other bug, for that matter - to include such code, but
>that does not mean that it should be made public.

Does this asymmetry in effort between the fix and the reproducer/exploit code
really exists these days? Point your favorite LLM at a commit that fixes an
issue and ask it to reproduce the problem. You'll likely end up with working
exploit code fairly quickly.

>The *fix* obviously should be public, and the commit message needs to
>explain the bug. And the threat of mandatory disclosure for any
>unfixed bug is a good way to keep people honest. But disclosing
>exploits after-the-fact as if everybody will have immediately
>upgraded? Asinine.

... which is why I think that our current security process, and security@k.o,
effectively does something similar to linux-distros@:

1. We end up bringing more attention to a particular issue once the fix is merged.
2. We make the issue public before users had a chance to upgrade.
3. Any "script kiddie" is then able to generate a working exploit from the
commit that fixes the issue.

Even without security@k.o, things like the syzkaller dashboard and the
vulns.git CVE repo are effectively a massive public library of vulnerabilities.

-- 
Thanks,
Sasha