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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, May 21, 2024 at 06:51:28PM +0200, Michal Hocko wrote:
> 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

Ah, missed that, sorry, was thinking about a different set of reverts
recently assigned.

> 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@linuxfoundation.org>
> Date:   Sun May 19 10:35:32 2024 +0200
> 
>     some 6.8.5 cves assigned
> 
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> which to me indicates that both CVEs were assigned by a script
> without a proper review which is really unfortunate.

Note, we have checks for many of these things, where we have an affected
kernel and a fix in the same release, and we do NOT assign a CVE for
those types of things.  This is the first time that I know of where we
have had this happen where the bug and revert was in the same release,
hard part here was that the revert didn't have a Fixes: tag, if it did,
we would have caught it.

> 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.

We will have a small % of issues that we miss and mess up like this,
that's just because we are all human.  Your help in reviewing these is
greatly appreciated.  Right now I still feel we are not catching all
that we should be catching to mark as a CVE, so we are open for anyone
to help us out with reviews.  Luckily we have a few more people helping
now as well, which is great.

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?

thanks,

greg k-h