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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZkzREEA5_N_xfqED@tiehlicka>
Date: Tue, 21 May 2024 18:51:28 +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 16:39:51, Greg KH wrote:
> On Tue, May 21, 2024 at 10:28:41AM +0200, Michal Hocko wrote:
> > CVE-2024-35881 to revert f341055b10bd ("drm/amd/display: Send DTBCLK
> > disable message on first commit") by 3a6a32b31a11 ("Revert
> > "drm/amd/display: Send DTBCLK disable message on first commit"") has
> > been filed as well.
> > 
> > Is this really intentional? Should both be rejected?
> 
> I don't think so as we had releases with the original commit in it,

I do not think so. Looking at stable kernel branches:
$ git describe-ver 0dab75b433ed2480d57ae4f8f725186a46223e42
v6.8.5~88
$ git describe-ver d6d5622f64f3e07620683d61c880f57965fe1b48
v6.8.5~239

Both of them were released in 6.9-rc1 in Linus tree. I do not see them
in any other stable trees. Neither of them is even marked for stable and
they seemed to be merged only because of (stable tree) 7ea8a0e12088eb0c
which has Stable-dep-of: f341055b10bd ("drm/amd/display: Send DTBCLK
disable message on first commit"). Btw note that 7ea8a0e12088eb0c is not
marked for stable, nor I see anybody requesting that on lore.
Stable rulez!

Let's put aside whether f341055b10bd should get a CVE, we have clearly a
different view on that but looking at the vulns.git tree both CVEs have
been assigned together
$ git log ./2024/CVE-2024-35906.sha1 ./2024/CVE-2024-35881.sha1
commit a6191f0053349c3234f690316d6511e97927f28f
Author: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Date:   Sun May 19 10:35:32 2024 +0200

    some 6.8.5 cves assigned

    Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>

which to me indicates that both CVEs were assigned by a script
without a proper review which is really unfortunate.

Please keep in mind that there are actual consumers of these CVEs and
you are burning their time evaluating these noops. A waste of time, if
you ask me, and not something that could be just neglected considering
how many CVEs you are producing.
-- 
Michal Hocko
SUSE Labs