[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <DIA5K5Z7Z1L3.LBWL4N5QTAFI@redcoat.dev>
Date: Mon, 04 May 2026 20:51:27 +0100
From: "Emily Shepherd" <emily@...coat.dev>
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 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.
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:
> Aside from your participation in discussions with the reporter and on
> the (linux-)distros lists (including possibly continuing to CC other
> prior recipients of the information), the information you receive
> through the (linux-)distros lists must not be made public, shared, nor
> even hinted at anywhere beyond the need-to-know within your distro's
> team except with the reporter's explicit approval, until the agreed
> upon public disclosure date/time or substantially complete publication
> by others. Neither you nor others you inform may use the information
> for anything other than getting the issue fixed for your distro's
> users and, only in rare extreme cases, for deployment of maximally
> non-revealing changes to maintain security of your distro's
> infrastructure most essential to the distro users' security in face of
> the security issue being dealt with. The need-to-know condition is met
> only if the person needs to participate in one of these two
> activities.
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.
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.
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.
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.
None of this is normal - why the Linux security team and CNA team even
talking amongst themselves internally? Why is it an external party's
job to coordinate that? 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.
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.
This tells a user nothing. What is the threat? Don't know. When does it
occur? Dunno. What impact did it have? *shrugs*. While I understand the
potential need to be vague in the commit message of the fix itself to
avoid drawing attention to it prior to the publication of the CVE, once
we get to CVE stage the whole point is surely to be informative about
the threat, who it effects, and how to mitigate against it. Compare any
Linux CVE description with those raised by other CNAs and Linux's come
up wanting every time.
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.
At the end of the day I am aware that Linux is an open source project,
and is maintained by volunteers, and I am therefore in no position to
say what MUST [3] - or even what SHOULD - be done. Given you did ask for
what could be better, however, I have given my thoughts, and I can
observe that the process that we have today is not a particularly strong
one.
[1]: https://docs.kernel.org/process/security-bugs.html
[2]: https://oss-security.openwall.org/wiki/mailing-lists/distros
[3]: https://www.rfc-editor.org/rfc/rfc2119
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.
