[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2026050727-outtakes-plus-c2de@gregkh>
Date: Thu, 7 May 2026 06:32:33 +0200
From: Greg KH <greg@...ah.com>
To: oss-security@...ts.openwall.com
Cc: Sam James <sam@...too.org>, Taeyang Lee <0wn@...ori.io>,
Brad Spengler <spender@...ecurity.net>,
Solar Designer <solar@...nwall.com>
Subject: Re: Precise disclosure contents for copyfail (Re:
CVE-2026-31431: CopyFail: linux local privilege scalation)
On Mon, May 04, 2026 at 08:51:27PM +0100, Emily Shepherd wrote:
> On Mon May 4, 2026 at 6:38 PM BST, Greg KH wrote:
> > Once it lands in Linus's tree, our role is over.
>
> I would - respectfully - disagree. To clarify, I am aware that that is
> the process as defined currently, but I am not sure that is the best
> that process could be. You asked in a previous message what could have
> been done better, so assuming that was meant sincerely, I'll provide
> some thoughts.
>
> The first hurdle a reporter must jump through is figuring out who to
> actually report to - the process as defined [1] suggests it should be
> the maintainer first, with the security team CC'd. There is also a handy
> script provided to figure out the correct maintainer, and an example
> given.
>
> However, the example shows the script being called with a whole load of
> flags (`--no-l`, `--no-r`, etc) without description. These flags are not
> explained, or at the very least the importance of `--no-l` is not
> stressed. As this flag excludes mailing lists from the addresses the
> script will give back it is, presumably, essential to use when
> determining who to report security issues to.
The flags are all documented in the script itself, I don't know exactly
what you would want us to do differently here. You don't have to use
the tool, we just offered a simple way to do so if you don't want to dig
through the MAINTAINERS file yourself.
> I would also disagree with the rather casual assertion of the
> documentation that:
>
> > In the Linux kernel, all official maintainers are trusted, so
> > the consequences of accidentally including the wrong maintainer are
> > essentially a bit more noise for that person, i.e. nothing dramatic.
>
> Most other organisations treat security reports as strictly and
> absolutely need-to-know, even among trusted members of a team. Compare,
> for example, this stance with that of the "linux-distros" mailing list
> [2], which is far stronger:
Sure, linux-distros can do what they want for their policy, but you
trust these kernel maintainers today for the work they do, why would you
not also trust them to handle security bugs? That's the only way we can
get the proper fixes done in a timely manner. You want the people who
know and are responsible for the code itself to do the work, not anyone
else.
So yes, the kernel security team trusts its maintainers, this is a good
thing and one that any sane group should also do.
> The conclusion I must reach, therefore, is it would be more secure if
> the process were simplified to *all* requests going to the security team
> address only, who then take responsibility for triaging and engaging the
> appropriate people.
What do you mean by "secure"? Are things leaking here in the current
process?
If you want things to move slower, then don't involved the maintainers,
and force a tiny group of people to do all the work on their own. That
does not scale and ends up with worse security overall. We aren't going
to do that.
> The submission process also places an extra-ordinarily high burden on
> the reporter, rather than the security team itself, to coordinate an
> appropriate response to bugs. As the process makes clear, the choice of
> when - or indeed if - to even inform linux-distros of an issue is left
> entirely up to the reporter, with a recommendation that they not be told
> at all until a fix is ready. It is, presumably, also the reporter's
> responsibility to monitor for a fix becoming ready.
A reporter has to coordinate nothing if they don't want to, we can't
force them. We don't coordinate anything except getting bugs fixed.
It's up to the submitter after that what they wish to do with anything.
The huge majority just are happy the bug is fixed, so all is good.
> The process also states:
>
> > DO NOT contact the "linux-distros" mailing list UNTIL... you have read
> > the distros wiki page above and you fully understand the requirements
> > that contacting “linux-distros” will impose on you and the kernel
> > community.
>
> Which is about as ominous and off-putting a statement that it would turn
> many organisations away from meaningfully engaging in the process at
> all.
Great, that's the intention! I don't want anyone to contact
linux-distros as it only causes more problems than it is worth. This
has been hashed out many times over the years on the list if you want
the details.
> The process also suggests that a CVE won't even be assigned for an issue
> unless the reporter - once again - takes the initiative for requesting
> one:
>
> > If a reporter wishes to have a CVE identifier assigned for a confirmed
> > issue, they can contact the kernel CVE assignment team to obtain one.
Yes.
> None of this is normal - why the Linux security team and CNA team even
> talking amongst themselves internally?
They do not, they are different groups of volunteers, doing all of this
work on their own time as individuals.
> Why is it an external party's job to coordinate that?
No one has to coordinate anything. A CVE will usually be assigned a
month or so after it lands in a public release. If someone wants one
sooner, just email and ask, we give them out on a daily basis.
> The reality is the team best suited to knowing how, and being subtly
> trustworthy, to co-ordinate security responses is almost always the
> team within the project itself, not the good Samaritan who did the
> reporting.
Again, we don't coordinate anything. The kernel security team's job is
to fix bugs and get them into public releases. That's it. The kernel
CVE's team is to assign CVEs to fixes that are in releases that meet the
requirements of what cve.org has put on them. That's it. No
coordination between the two is needed.
> Finally the CVEs themselves; their descriptions are - frankly -
> appalling. The CVE description in this case was:
>
> > In the Linux kernel, the following vulnerability has been resolved:
> >
> > crypto: algif_aead - Revert to operating out-of-place
> >
> > This mostly reverts commit 72548b093ee3 except for the copying of
> > the associated data.
> >
> > There is no benefit in operating in-place in algif_aead since the
> > source and destination come from different mappings. Get rid of
> > all the complexity added for in-place operation and just copy the
> > AD directly.
We take the changelog text directly for the CVE. Yes, sometimes it is
horrid. Sometimes it is not. At our scale this is the only way we can
do it to start with for the initial report. After that, if people wish
to change the text, we gladly take patches and modifications of the
text, the ids, or almost anything else that is in the CVE entry. Just
send us a patch, the whole repo is in git and we have documentation in
the repo for how to do this.
> Ultimately, none of these points are theoretical. While I am frustrated
> with the reporters for not following the process as defined in this
> case, which has led to a pretty disastrous disclosure all round, the
> result is a prime example of what was always going to happen sooner or
> later with a disclosure process so opaque and seemingly hostile.
Hostile to whom? Distros that do not follow the stable kernel releases?
thanks,
greg k-h
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
