Multiple potential integer overflow in raw2tiff.c in libtiff <= 4.5.1 can allow remote attackers to cause a denial of service (application crash) or possibly execute an arbitrary code via a crafted tiff image which triggers a heap-based buffer overflow.
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.