[PATCH vulns 0/1] change the sha1 for CVE-2024-26661

[PATCH vulns 0/1] change the sha1 for CVE-2024-26661

[Qingfeng Hao]

There is a fix 17ba9cde11c2bfebbd70867b0a2ac4a22e573379
introduced in v6.8 to fix the problem introduced by
the original fix 66951d98d9bf45ba25acf37fe0747253fafdf298,
and they together fix the CVE-2024-26661.
Since this is the first time I submit the changes on vulns project,
not sure if the changes in my patch are exact, @Greg, please point 
out the problems if there are and I will fix them.

Thanks!

Qingfeng Hao (1):
  CVE-2024-26661: change the sha1 of the cve id

 cve/published/2024/CVE-2024-26661.dyad |  6 ++--
 cve/published/2024/CVE-2024-26661.json | 46 ++------------------------
 cve/published/2024/CVE-2024-26661.sha1 |  2 +-
 3 files changed, 5 insertions(+), 49 deletions(-)

-- 
2.34.1

[PATCH vulns 1/1] CVE-2024-26661: change the sha1 of the cve id

[Qingfeng Hao]

There is a fix 17ba9cde11c2bfebbd70867b0a2ac4a22e573379
introduced in v6.8 to fix the problem introduced by
the original fix 66951d98d9bf45ba25acf37fe0747253fafdf298,
and they together fix the CVE-2024-26661.
Hence, update the cve files accordingly.

Signed-off-by: Qingfeng Hao <qingfeng.hao@windriver.com>
Signed-off-by: He Zhe <zhe.he@windriver.com>
---
 cve/published/2024/CVE-2024-26661.dyad |  6 ++--
 cve/published/2024/CVE-2024-26661.json | 46 ++------------------------
 cve/published/2024/CVE-2024-26661.sha1 |  2 +-
 3 files changed, 5 insertions(+), 49 deletions(-)

diff --git a/cve/published/2024/CVE-2024-26661.dyad b/cve/published/2024/CVE-2024-26661.dyad
index 120c36d66..fc4c2091d 100644
--- a/cve/published/2024/CVE-2024-26661.dyad
+++ b/cve/published/2024/CVE-2024-26661.dyad
@@ -1,5 +1,3 @@
 # dyad version: 86b352798e93
-# 	getting vulnerable:fixed pairs for git id 66951d98d9bf45ba25acf37fe0747253fafdf298
-5.9:474ac4a875ca6fea3fc5183d3ad22ef7523dca53:6.6.17:3f3c237a706580326d3b7a1b97697e5031ca4667
-5.9:474ac4a875ca6fea3fc5183d3ad22ef7523dca53:6.7.5:39f24c08363af1cd945abad84e3c87fd3e3c845a
-5.9:474ac4a875ca6fea3fc5183d3ad22ef7523dca53:6.8:66951d98d9bf45ba25acf37fe0747253fafdf298
+# 	getting vulnerable:fixed pairs for git id 17ba9cde11c2bfebbd70867b0a2ac4a22e573379
+5.9:474ac4a875ca6fea3fc5183d3ad22ef7523dca53:6.8:17ba9cde11c2bfebbd70867b0a2ac4a22e573379
diff --git a/cve/published/2024/CVE-2024-26661.json b/cve/published/2024/CVE-2024-26661.json
index 91d11967b..7c7b2a818 100644
--- a/cve/published/2024/CVE-2024-26661.json
+++ b/cve/published/2024/CVE-2024-26661.json
@@ -22,19 +22,7 @@
                "versions": [
                   {
                      "version": "474ac4a875ca6fea3fc5183d3ad22ef7523dca53",
-                     "lessThan": "3f3c237a706580326d3b7a1b97697e5031ca4667",
-                     "status": "affected",
-                     "versionType": "git"
-                  },
-                  {
-                     "version": "474ac4a875ca6fea3fc5183d3ad22ef7523dca53",
-                     "lessThan": "39f24c08363af1cd945abad84e3c87fd3e3c845a",
-                     "status": "affected",
-                     "versionType": "git"
-                  },
-                  {
-                     "version": "474ac4a875ca6fea3fc5183d3ad22ef7523dca53",
-                     "lessThan": "66951d98d9bf45ba25acf37fe0747253fafdf298",
+                     "lessThan": "17ba9cde11c2bfebbd70867b0a2ac4a22e573379",
                      "status": "affected",
                      "versionType": "git"
                   }
@@ -59,18 +47,6 @@
                      "status": "unaffected",
                      "versionType": "semver"
                   },
-                  {
-                     "version": "6.6.17",
-                     "lessThanOrEqual": "6.6.*",
-                     "status": "unaffected",
-                     "versionType": "semver"
-                  },
-                  {
-                     "version": "6.7.5",
-                     "lessThanOrEqual": "6.7.*",
-                     "status": "unaffected",
-                     "versionType": "semver"
-                  },
                   {
                      "version": "6.8",
                      "lessThanOrEqual": "*",
@@ -87,18 +63,6 @@
                      "operator": "OR",
                      "negate": false,
                      "cpeMatch": [
-                        {
-                           "vulnerable": true,
-                           "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
-                           "versionStartIncluding": "5.9",
-                           "versionEndExcluding": "6.6.17"
-                        },
-                        {
-                           "vulnerable": true,
-                           "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
-                           "versionStartIncluding": "5.9",
-                           "versionEndExcluding": "6.7.5"
-                        },
                         {
                            "vulnerable": true,
                            "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
@@ -112,13 +76,7 @@
          ],
          "references": [
             {
-               "url": "https://git.kernel.org/stable/c/3f3c237a706580326d3b7a1b97697e5031ca4667"
-            },
-            {
-               "url": "https://git.kernel.org/stable/c/39f24c08363af1cd945abad84e3c87fd3e3c845a"
-            },
-            {
-               "url": "https://git.kernel.org/stable/c/66951d98d9bf45ba25acf37fe0747253fafdf298"
+               "url": "https://git.kernel.org/stable/c/17ba9cde11c2bfebbd70867b0a2ac4a22e573379"
             }
          ],
          "title": "drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'",
diff --git a/cve/published/2024/CVE-2024-26661.sha1 b/cve/published/2024/CVE-2024-26661.sha1
index 2e7b06c75..b6301aa3c 100644
--- a/cve/published/2024/CVE-2024-26661.sha1
+++ b/cve/published/2024/CVE-2024-26661.sha1
@@ -1 +1 @@
-66951d98d9bf45ba25acf37fe0747253fafdf298
+17ba9cde11c2bfebbd70867b0a2ac4a22e573379
-- 
2.34.1

Re: [PATCH vulns 0/1] change the sha1 for CVE-2024-26661

[Greg KH]

On Fri, Aug 01, 2025 at 12:06:34PM +0800, Qingfeng Hao wrote:
> There is a fix 17ba9cde11c2bfebbd70867b0a2ac4a22e573379
> introduced in v6.8 to fix the problem introduced by
> the original fix 66951d98d9bf45ba25acf37fe0747253fafdf298,
> and they together fix the CVE-2024-26661.

Those are two different things, shouldn't they get different CVE ids?

> Since this is the first time I submit the changes on vulns project,
> not sure if the changes in my patch are exact, @Greg, please point 
> out the problems if there are and I will fix them.

There's never a need to modify the .dyad or .json files (hint, you also
did not touch the .mbox file.)  they are all auto-generated from the
.sha1 file.

But again, I don't think this is correct, either this specific CVE is
not a CVE (i.e. it doesn't actually fix an issue), or we need to assign
another one, right?

thanks,

greg k-h

RE: [PATCH vulns 0/1] change the sha1 for CVE-2024-26661

[Hao, Qingfeng]

Hi Greg,
Thanks for your check and comments. Sorry that I mistakenly changed 
the files of .dyad and .json. I'll pay attention next time. 
The original fix 66951d98d9bf ("drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'") 
or fb5a3d037082 for CVE-2024-26661 didn't fix the CVE (or even made it worse) because the key change 
is to check if “tg” is NULL before referencing it, but the fix does NOT do that correctly:
+       if (!abm && !tg && !panel_cntl) 
+               return; 
Here "&&" should have been "||".
The follow-up commit 17ba9cde11c2 fixes this by:
-       if (!abm && !tg && !panel_cntl) 
+       if (!abm || !tg || !panel_cntl) 
                return; 
So we consider that 66951d98d9bf is not a complete fix. It actually made things worse.
66951d98d9bf and 17ba9cde11c2 together fix CVE-2024-26661.
The same problem happened to CVE-2024-26662.
If you agree with the above analysis, should I append 17ba9cde11c2bfebbd70867b0a2ac4a22e573379 to CVE-2024-26661.sha1 ? 

Thanks! 

Qingfeng

-----Original Message-----
From: Greg KH <gregkh@linuxfoundation.org> 
Sent: 2025年8月1日 15:41
To: Hao, Qingfeng <Qingfeng.Hao@windriver.com>
Cc: cve@kernel.org; stable@vger.kernel.org; He, Zhe <Zhe.He@windriver.com>
Subject: Re: [PATCH vulns 0/1] change the sha1 for CVE-2024-26661

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Fri, Aug 01, 2025 at 12:06:34PM +0800, Qingfeng Hao wrote:
> There is a fix 17ba9cde11c2bfebbd70867b0a2ac4a22e573379
> introduced in v6.8 to fix the problem introduced by the original fix 
> 66951d98d9bf45ba25acf37fe0747253fafdf298,
> and they together fix the CVE-2024-26661.

Those are two different things, shouldn't they get different CVE ids?

> Since this is the first time I submit the changes on vulns project, 
> not sure if the changes in my patch are exact, @Greg, please point out 
> the problems if there are and I will fix them.

There's never a need to modify the .dyad or .json files (hint, you also did not touch the .mbox file.)  they are all auto-generated from the
.sha1 file.

But again, I don't think this is correct, either this specific CVE is not a CVE (i.e. it doesn't actually fix an issue), or we need to assign another one, right?

thanks,

greg k-h

Re: [PATCH vulns 0/1] change the sha1 for CVE-2024-26661

[Greg KH]

On Fri, Aug 01, 2025 at 12:04:54PM +0000, Hao, Qingfeng wrote:
> Hi Greg,
> Thanks for your check and comments. Sorry that I mistakenly changed 
> the files of .dyad and .json. I'll pay attention next time. 
> The original fix 66951d98d9bf ("drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'") 
> or fb5a3d037082 for CVE-2024-26661 didn't fix the CVE (or even made it worse) because the key change 
> is to check if “tg” is NULL before referencing it, but the fix does NOT do that correctly:
> +       if (!abm && !tg && !panel_cntl) 
> +               return; 
> Here "&&" should have been "||".
> The follow-up commit 17ba9cde11c2 fixes this by:
> -       if (!abm && !tg && !panel_cntl) 
> +       if (!abm || !tg || !panel_cntl) 
>                 return; 
> So we consider that 66951d98d9bf is not a complete fix. It actually made things worse.
> 66951d98d9bf and 17ba9cde11c2 together fix CVE-2024-26661.
> The same problem happened to CVE-2024-26662.
> If you agree with the above analysis, should I append 17ba9cde11c2bfebbd70867b0a2ac4a22e573379 to CVE-2024-26661.sha1 ? 

I think that the original CVE should just be rejected and a new one
added for the other sha1 you have pointed out that actually fixes the
issue because the first one does not do anything.  Is that ok?

thanks,

greg k-h

Re: [PATCH vulns 0/1] change the sha1 for CVE-2024-26661

[Qingfeng Hao]

On 8/2/25 16:19, Greg KH wrote:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On Fri, Aug 01, 2025 at 12:04:54PM +0000, Hao, Qingfeng wrote:
>> Hi Greg,
>> Thanks for your check and comments. Sorry that I mistakenly changed
>> the files of .dyad and .json. I'll pay attention next time.
>> The original fix 66951d98d9bf ("drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'")
>> or fb5a3d037082 for CVE-2024-26661 didn't fix the CVE (or even made it worse) because the key change
>> is to check if “tg” is NULL before referencing it, but the fix does NOT do that correctly:
>> +       if (!abm && !tg && !panel_cntl)
>> +               return;
>> Here "&&" should have been "||".
>> The follow-up commit 17ba9cde11c2 fixes this by:
>> -       if (!abm && !tg && !panel_cntl)
>> +       if (!abm || !tg || !panel_cntl)
>>                  return;
>> So we consider that 66951d98d9bf is not a complete fix. It actually made things worse.
>> 66951d98d9bf and 17ba9cde11c2 together fix CVE-2024-26661.
>> The same problem happened to CVE-2024-26662.
>> If you agree with the above analysis, should I append 17ba9cde11c2bfebbd70867b0a2ac4a22e573379 to CVE-2024-26661.sha1 ?
> I think that the original CVE should just be rejected and a new one
> added for the other sha1 you have pointed out that actually fixes the
> issue because the first one does not do anything.  Is that ok?
Thanks Greg.
Just to be clear, 66951d98d9bf was supposed to fix CVE-2024-26661 but it 
failed
to do that. Then 17ba9cde11c2 was added, together with 66951d98d9bf, finally
fixing CVE-2024-26661.

1) I'm OK with rejecting CVE-2024-26661 and creating a new CVE.
BTW, since I'm new to kernel CVE management, why do we reject a valid 
CVE just
because the initial fix doesn't work ?

2) If we do need to reject CVE-2024-26661 and create a new CVE, is there
anything I should do ?

3) I just did some search and found that some sha1 files contain multiple
commit ids. The sha1 file should contain all of the commits that fix the 
CVE ?
Or just the last commit of the commits that fix the CVE ?

Thanks!
Qingfeng
>
> thanks,
>
> greg k-h

Re: [PATCH vulns 0/1] change the sha1 for CVE-2024-26661

[Greg KH]

On Mon, Aug 04, 2025 at 03:47:16PM +0800, Qingfeng Hao wrote:
> 
> On 8/2/25 16:19, Greg KH wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and know the content is safe.
> > 
> > On Fri, Aug 01, 2025 at 12:04:54PM +0000, Hao, Qingfeng wrote:
> > > Hi Greg,
> > > Thanks for your check and comments. Sorry that I mistakenly changed
> > > the files of .dyad and .json. I'll pay attention next time.
> > > The original fix 66951d98d9bf ("drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'")
> > > or fb5a3d037082 for CVE-2024-26661 didn't fix the CVE (or even made it worse) because the key change
> > > is to check if “tg” is NULL before referencing it, but the fix does NOT do that correctly:
> > > +       if (!abm && !tg && !panel_cntl)
> > > +               return;
> > > Here "&&" should have been "||".
> > > The follow-up commit 17ba9cde11c2 fixes this by:
> > > -       if (!abm && !tg && !panel_cntl)
> > > +       if (!abm || !tg || !panel_cntl)
> > >                  return;
> > > So we consider that 66951d98d9bf is not a complete fix. It actually made things worse.
> > > 66951d98d9bf and 17ba9cde11c2 together fix CVE-2024-26661.
> > > The same problem happened to CVE-2024-26662.
> > > If you agree with the above analysis, should I append 17ba9cde11c2bfebbd70867b0a2ac4a22e573379 to CVE-2024-26661.sha1 ?
> > I think that the original CVE should just be rejected and a new one
> > added for the other sha1 you have pointed out that actually fixes the
> > issue because the first one does not do anything.  Is that ok?
> Thanks Greg.
> Just to be clear, 66951d98d9bf was supposed to fix CVE-2024-26661 but it
> failed
> to do that. Then 17ba9cde11c2 was added, together with 66951d98d9bf, finally
> fixing CVE-2024-26661.
> 
> 1) I'm OK with rejecting CVE-2024-26661 and creating a new CVE.
> BTW, since I'm new to kernel CVE management, why do we reject a valid CVE
> just
> because the initial fix doesn't work ?

Because almost all CVEs are tied to the commits that resolve them.  But,
we do have a way to have multiple commit ids for a single CVE, as you
point out, so we should probably just do that here as well.

> 2) If we do need to reject CVE-2024-26661 and create a new CVE, is there
> anything I should do ?

Nope!

> 3) I just did some search and found that some sha1 files contain multiple
> commit ids. The sha1 file should contain all of the commits that fix the CVE
> ?
> Or just the last commit of the commits that fix the CVE ?

Let me just go and add this id to the CVE itself, as it makes more sense
as you point out, both commits need to be present here to resolve the
issue.

I've now done that, but note, it didn't change anything here, the fixes
and vulnerable entries still all remain the same, so no one really will
notice this :)

thanks,

greg k-h