Bug 2224971

This CVE is referenced at https://gitlab.com/libtiff/libtiff/-/issues/591 (but it looks the content of this RHBZ is swapped with CVE-2023-38289).

In reply to comment #3:
> This CVE is referenced at https://gitlab.com/libtiff/libtiff/-/issues/591
> (but it looks the content of this RHBZ is swapped with CVE-2023-38289).

Hi, These CVEs are assigned by us (Red Hat CNA), CVEs attached to the bugs are from the final vulnerabilities report sent by the reporter. I am discussing about this issue with the reporter to rectify from his end.

Hi,

(In reply to Dhananjay Arunesh from comment #4)
> In reply to comment #3:
> > This CVE is referenced at https://gitlab.com/libtiff/libtiff/-/issues/591
> > (but it looks the content of this RHBZ is swapped with CVE-2023-38289).
> 
> Hi, These CVEs are assigned by us (Red Hat CNA), CVEs attached to the bugs
> are from the final vulnerabilities report sent by the reporter. I am
> discussing about this issue with the reporter to rectify from his end.

As this currently causes confusion, as depending where you look you have 
different CVEs swappend, did the reporter agreed on fixing this annotation
on his end?

Would it be easier to swap the CVEs at RedHat CNA, as there were no RedHat
updates yet fixing those issues?

Thanks already in advance for looking into it,

Regards,
Salvatore

In reply to comment #5:
> Hi,
> 
> (In reply to Dhananjay Arunesh from comment #4)
> > In reply to comment #3:
> > > This CVE is referenced at https://gitlab.com/libtiff/libtiff/-/issues/591
> > > (but it looks the content of this RHBZ is swapped with CVE-2023-38289).
> > 
> > Hi, These CVEs are assigned by us (Red Hat CNA), CVEs attached to the bugs
> > are from the final vulnerabilities report sent by the reporter. I am
> > discussing about this issue with the reporter to rectify from his end.
We don't have any response from the reporter.
> As this currently causes confusion, as depending where you look you have 
> different CVEs swappend, did the reporter agreed on fixing this annotation
> on his end?
> 
> Would it be easier to swap the CVEs at RedHat CNA, as there were no RedHat
> updates yet fixing those issues?
> 
The CVEs are assigned by Red Hat and I can check the CVEs are public at many places so instead of swapping the CVEs best option is to reject the CVEs and re-assign the flaws with new CVEs.
> Thanks already in advance for looking into it,
> 
> Regards,
> Salvatore

(In reply to Dhananjay Arunesh from comment #6)
> In reply to comment #5:
> > Hi,
> > 
> > (In reply to Dhananjay Arunesh from comment #4)
> > > In reply to comment #3:
> > > > This CVE is referenced at https://gitlab.com/libtiff/libtiff/-/issues/591
> > > > (but it looks the content of this RHBZ is swapped with CVE-2023-38289).
> > > 
> > > Hi, These CVEs are assigned by us (Red Hat CNA), CVEs attached to the bugs
> > > are from the final vulnerabilities report sent by the reporter. I am
> > > discussing about this issue with the reporter to rectify from his end.
> We don't have any response from the reporter.

Okay too bad :(

> > As this currently causes confusion, as depending where you look you have 
> > different CVEs swappend, did the reporter agreed on fixing this annotation
> > on his end?
> > 
> > Would it be easier to swap the CVEs at RedHat CNA, as there were no RedHat
> > updates yet fixing those issues?
> > 
> The CVEs are assigned by Red Hat and I can check the CVEs are public at many
> places so instead of swapping the CVEs best option is to reject the CVEs and
> re-assign the flaws with new CVEs.

Alright, this is indeed an option. For instance the Debian LTS project covering
older suites not anymore covered by the regular security support issued already
an update referencing the CVEs above. Samewise did Ubuntu in USN-6290-1.

Not sure about other distribuions.

Regards,
Salvatore

I see now both are rejected 

https://www.cve.org/CVERecord?id=CVE-2023-38288
and
https://www.cve.org/CVERecord?id=CVE-2023-38289

with "Rejected Reason: Not a Security Issue.".

I'm now highly confused.

*** This bug has been marked as a duplicate of bug 2235264 ***

In reply to comment #7:
> (In reply to Dhananjay Arunesh from comment #6)
> > In reply to comment #5:
> > > Hi,
> > > 
> > > (In reply to Dhananjay Arunesh from comment #4)
> > > > In reply to comment #3:
> > > > > This CVE is referenced at https://gitlab.com/libtiff/libtiff/-/issues/591
> > > > > (but it looks the content of this RHBZ is swapped with CVE-2023-38289).
> > > > 
> > > > Hi, These CVEs are assigned by us (Red Hat CNA), CVEs attached to the bugs
> > > > are from the final vulnerabilities report sent by the reporter. I am
> > > > discussing about this issue with the reporter to rectify from his end.
> > We don't have any response from the reporter.
> 
> Okay too bad :(
> 
> > > As this currently causes confusion, as depending where you look you have 
> > > different CVEs swappend, did the reporter agreed on fixing this annotation
> > > on his end?
> > > 
> > > Would it be easier to swap the CVEs at RedHat CNA, as there were no RedHat
> > > updates yet fixing those issues?
> > > 
> > The CVEs are assigned by Red Hat and I can check the CVEs are public at many
> > places so instead of swapping the CVEs best option is to reject the CVEs and
> > re-assign the flaws with new CVEs.
> 
> Alright, this is indeed an option. For instance the Debian LTS project
> covering
> older suites not anymore covered by the regular security support issued
> already
> an update referencing the CVEs above. Samewise did Ubuntu in USN-6290-1.
> 
> Not sure about other distribuions.
> 
> Regards,
> Salvatore

Rejected the old CVE and re-assigned the vulnerability with new flaw and CVE. Please track the below link[0] for more information.
https://bugzilla.redhat.com/show_bug.cgi?id=2235264

Regardng the comment for the old CVE (as Not a security issue) on Mitre, we are working to correct the statement.