Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 29 Aug 2017 22:02:28 +0200
From: Agostino Sarubbo <>
Subject: Re: Re: [scr379303] A bunch of duplicate CVEs requested for?? bho..

Hello Mitre, I'm glad to see your response here.

On martedì 29 agosto 2017 21:23:50 CEST wrote:
> > duplicate of:
> >
> Yes, these are duplicates; we will reject CVE-2017-13753 and update
> CVE-2016-9396.
The problem is not about this duplicate but from some assignments in the last 
two months from people I mentioned, see the first post here from a partial 

> This occurred because the MITRE CVE team inadvertently populated
> CVE-2016-9396 with incorrect version information, 
This is right

> and because the code
> changed between the two tested versions.
from we have: 
libjasper/jpc/jpc_t1cod.c:144: int JPC_NOMINALGAIN(int, int, int, int): 
Assertion `qmfbid == 0x01′ failed.
form we have:
libjasper/jpc/jpc_t1cod.c:144: int JPC_NOMINALGAIN(int, int, int, int): 
Assertion `qmfbid == JPC_COX_RFT' failed.

they looks to be similar.

> Specifically, CVE-2016-9396 had said "in JasPer before 1.900.12" but
> actually there was no reference stating that 1.900.12 was a fixed
> version. Also, the CVE-2017-13753 reference said "Assertion `qmfbid ==
> JPC_COX_RFT' failed" but the CVE-2016-9396 reference said "Assertion
> `qmfbid == 0x01' failed." These happen to be the same (there's a
> "#define JPC_COX_RFT 0x01" elsewhere), but it initially looked like
> the new report was about a different assertion that was problematic in
> 1.900.12 and later versions.
From your side looks to be correct, What I'm trying to point out is to not 
trust at all cve-requests that never went under upstream eyes.

> > months later we have:
> >
> > "There is a division-by-zero vulnerability in LAME 3.99.5, caused by a
> > malformed input file."
> When we worked on your CVE ID request for the
> ader-get_audio-c/ report, we had the information about the affected
> source-code pathname frontend/get_audio.c, and we had found the
> information about "this is all in the
> frontend code in frontend/get_audio.c:parse_wave_header() and not in
> the library." By contrast, the CVE-2017-11720 request had less
> technical detail about the source-code location, and the requester had
> checked the "Has vendor confirmed or acknowledged the vulnerability?"
This is right from your side, but looks to be false in the reality. The cve 
was issued on 07/28/2017 while the first comment from upstream was on 
08/13/2017 ( Again do not entirely 
trust request that never went under upstream eyes.

> Yes box on our web site. In general, if a
> problem is only a divide-by-zero in a command-line program, but the
> upstream vendor decided to categorize it as a vulnerability, then it
> gets a CVE. Admittedly, there was no direct proof of "decided to
> categorize it as a vulnerability" here. Also, if a CVE is already
> populated, and is about this type of valid crash report, then we do
> not retroactively reject it, even if we learn more about exploitation
> relevance. We will update CVE-2017-11720 with your reference, to help
> to show that you were the original discoverer.

As said to Henri in my previous email, the problem is not the FPE itself or 
something technical.
As you can clearly see I'm trying to include the asan output on each bug I 
find, to make it easily-comparable and sometimes you can easily understand the 
cause/nature of the issue. Unfortunately people do not do the same and this 
causes the presence of duplicates.

Agostino Sarubbo
Gentoo Linux Developer

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.