Am Wed, Apr 21, 2021 at 12:03:59PM +0200 schrieb Mattias Ellert:
> tis 2021-04-20 klockan 20:32 +0200 skrev Moritz Muehlenhoff:
> > Package: libgsoap-2.8.104
> > Version: 2.8.104-2
> > Severity: important
> > File: gsoap
> > Tags: security
> > X-Debbugs-Cc: Debian Security Team <[email protected]>
> >
> > This was assigned CVE-2021-21783:
> > https://talosintelligence.com/vulnerability_reports/TALOS-2021-1245
> >
> > Cheers,
> > Moritz
>
> Hi Moritz.
>
> I can not fully comprehend this bug report.
>
> If I read the CVE-2021-21783 report, it basically says:
>
> We have noticed that the vulnerability we previously reported
> (CVE-2020-13576) was not fixed. We have therefore resubmitted it.
> We have investigated the following versions:
>
> Genivia gSOAP 2.8.109
> Genivia gSOAP 2.8.110
>
> However, the fix for CVE-2020-13576 was in gSOAP 2.8.111, so that this
> was still present in the two tested versions is expected.
>
> The page for previous CVE-2020-13576 does claim that it was fixed in an
> upstream release on 2020-11-20, which corresponds to version 2.8.109.
>
> I do not think this statement is correct. From my understanding of
> comparing the reported fault (including code snippets) with the changes
> to the source repository, I understand it to have been fixed in version
> 2.8.111, and not in 2.8.109 as the report claims. Since the reported
> fixed version in incorrect I can see why it was reported again.
>
> I think the reason for the wrong fixed version in the previous report
> is that the other 4 CVEs reported against gsoap at the same time
> (CVE-2020-13574, CVE-2020-13575, CVE-2020-13577 and CVE-2020-13578)
> were indeed fixed in version 2.8.109. So someone might just put the
> same fixed date on all 5 reports.
>
> The fix for CVE-2020-13576 from version 2.8.111 is already applied as a
> patch in the debian package version gsoap/2.8.104-3. And if this new
> CVE is indeed a duplicate there is nothing more to fix.
Thanks, I agreed with what you summarised. This seems like an error at
TALOS. Probably the CVE should be rejected entirely, but for now I'll
simply mark it as a non-issue in the Debian Security Tracker.
Cheers,
Moritz
