linux-kernel - Re: CVE-2024-35906: drm/amd/display: Send DTBCLK disable message on first commit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 21 May 2024 19:56:54 +0200
From: Michal Hocko <mhocko@...e.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: cve@...nel.org, linux-kernel@...r.kernel.org,
	linux-cve-announce@...r.kernel.org
Subject: Re: CVE-2024-35906: drm/amd/display: Send DTBCLK disable message on
 first commit

On Tue 21-05-24 19:03:58, Greg KH wrote:
> On Tue, May 21, 2024 at 06:51:28PM +0200, Michal Hocko wrote:
[...]
> And really, in the end, if you have a "CVE and fix for CVE" in the same
> release, applying both doesn't hurt anyone, so this is a "fail secure"
> mode for everyone, right?

Look Greg, we have been through this discussion at several occasions and
I do not want to repeat that again. Stable tree users probably do not
care because they are getting all these patches, including regressions
and patches they do not need or even want, anyway. They are getting what
they are _paying_ for. Marking them CVE doesn't make any difference. But
stable tree backporting model is simply not a good fit for _many_ users.

Now, for $reasons, people _do_ care about CVEs and that is why there is
an engineering cost on downstreams to review them. Exactly because
applying all of them blindly is a _risk_. Exactly because the stable
backporting model/policy and CVE assigning policy is simply incompatible
with the stability/correctness/performance/$other requirements. 

I completely do get why you do not care about that downstream
engineering cost but generating bogus CVEs on top of a huge pile of
dubious ones is less than useful, don't you think?

Seriously, we can disagree whether something is a security threat that
is worth marking by a CVE. But making the CVE generation process mostly
unattended script driven process without any _serious_ review in place
is burning a lot of man power that could be used in a much more
productive way. This is not the way how to convince people to use stable
kernels.

Bye
-- 
Michal Hocko
SUSE Labs