Closed utkarsh2102 closed 3 years ago
All of your assumptions are correct.
Clarity on CVE-2018-19840 is that that change is actually a subset of the very recent fix for CVE-2020-35738, so it really shouldn't be its own patch (i.e. there's no reason to check for zero, then check for less than or equal to zero).
On CVE-2019-1010319, that is totally new code that doesn't exist before 5.0. The CLEAR (WaveHeader)
you are referring to in 4.70 now resides the file cli/riff.c
. But yes, no change required.
Thanks so much for attending to this!
Hello 👋🏻
Clarity on CVE-2018-19840 is that that change is actually a subset of the very recent fix for CVE-2020-35738, so it really shouldn't be its own patch (i.e. there's no reason to check for zero, then check for less than or equal to zero).
Oh yes! I just marked both as fixed with the recent patch applied! Thank you, though!
On CVE-2019-1010319, that is totally new code that doesn't exist before 5.0. The
CLEAR (WaveHeader)
you are referring to in 4.70 now resides the filecli/riff.c
. But yes, no change required.
Perfect, thank you!
Thanks so much for attending to this!
No, thank you so much for your review and great help on this! ❤️
Hello @dbry,
I am incredibly thankful for your help for CVE-2020-35738 wrt 4.70.0. As mentioned there already, I am fixing all the pending security vulnerabilities for Debian ELTS which is at version 4.70.0.
I have carefully reviewed and backported all that I could find. Here's my take on this:
src/read_words.c
of the fixing commit. The initial hunk wasn't a part of the older version.CLEAR (WaveHeader);
was already in v4.70.0. So I guess this is not affecting that version. Right?If you have some time (and can take a quick look at this), could you help me verify that this is indeed correct? Based on this, I'll also backport to v5.0.0, where some of these are already fixed.