[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2026050155-yelp-bonnet-bfd2@gregkh>
Date: Fri, 1 May 2026 08:11:24 +0200
From: Greg KH <greg@...ah.com>
To: oss-security@...ts.openwall.com
Cc: contact@...ori.io
Subject: Re: CVE-2026-31431: CopyFail: linux local privilege
scalation
On Fri, May 01, 2026 at 05:21:46AM +0200, Solar Designer wrote:
> Hi Greg,
>
> Thank you for commenting on this.
>
> On Thu, Apr 30, 2026 at 06:52:15PM +0200, Greg KH wrote:
> > On Thu, Apr 30, 2026 at 03:17:45AM -0400, cyber security wrote:
> > > That is very terrifying, is it is 10.0 score?
> >
> > There is a score in the CVE entry, does that not show up properly for
> > people somehow?
>
> It does. I guess someone top-posting a one-liner couldn't have bothered
> to check before posting or just wanted to share the emotions or provoke
> a discussion of CVSS scoring. Luckily, your reply actually adds value:
My reply was snarky, sorry about that, it was a long day...
> > This was one of the few CVE ids that we have provided a score for, why
> > people ignored that is confusing. You should contact your distro if you
> > are paying for support to find out why this happened as it should have
> > been covered by your support contract.
>
> That's interesting perspective. I just went to see whether a distro
> vendor could reasonably use this as a signal to prioritize this CVE fix.
> Here's what I did (after looking with my eyes to see the pattern first):
>
> git clone https://git.kernel.org/pub/scm/linux/security/vulns.git
> cd vulns
> git log | grep -B3 'Add CVSS' | grep -c 'Apr 25 .* 2026'
>
> This says 168. That's how many CVEs your team (this time, Sasha Levin)
> kindly scored on Saturday, April 25. So ~4 days prior to this one CVE
> making the news, ~2 days of which were the weekend. This CVE got a CVSS
> score of 7.8. The rest of the 168 got scores from 7.1 to 9.8. By the
> score alone, this one really does not stand out. To me, this is usual
> noise, with little signal in there.
The scores should be the signal, what else can we do here? And is the
9.8 being also ignored?
> Now, your team's message may be: distros can't possibly fix all kernel
> CVEs, not even those you provide high CVSS scores for, and especially
> not quickly enough, other than by staying with mainline or upstream
> stable/longterm kernels. Is this your actual and only message - not
> that distros should have magically seen the needle in the haystack?
No, our teams constant message is "you must update to the latest release
to get all fixes needed to keep a system secure of all currently-known
issues". That has not changed for decades now.
> The scoring reasoning for this CVE does not hint at its severity and the
> threat being imminent. It's as obscure as most of the rest of 168 are
> (which for most of them is probably a result of actually not having
> exploitability and impact analysis).
Why do you think that we knew this was "imminent"? The CVE team has no
such knowlege as no one is obligated to tell us that they are about to
let loose a trivial exploit.
> I understand not wanting to draw attention to a CVE that wasn't fully
> disclosed by the researchers yet, but you can't simultaneously say that
> _this_ was the heads-up to distros - it wasn't.
Again, I was being snarky as we all knew this would eventually happen
and it finally did.
> Please don't get me wrong, I appreciate the extra effort your team is
> taking to process some kernel bugs as CVEs and even to score them. I
> understand that with so many, quality can't be perfect.
>
> It's just that instead of drowning in the CVE/CVSS noise, we need a
> high-quality signal for CVEs that matter the most. Things that would
> certainly have been CVEs even prior to Linux CNA setup. They may not
> score the highest per CVSS, but in many cases - like in this one - your
> team has the knowledge that an issue is to become high-profile, so a
> timely direct heads-up to linux-distros would be appreciated. Where by
> "timely" I mean, say, a week (and never more than 14 days) before
> planned full public disclosure. We don't normally like to sit on
> semi-embargoed issues with public fixes, but we did introduce an
> exception for "Linux kernel issues concurrently or very recently handled
> by the Linux kernel security team" specifically to accommodate the way
> your team works.
>
> How does this sound to you?
Nope, sorry, we are NOT allowed to notify anyone about anything "ahead
of time" otherwise we will have to tell everyone about everything.
That's the only policy by which all the legal/governmental agencies
have agreed to allow us to operate in, so we are stuck with it.
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.
