-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello.
I prepared LTS security update for graphite2[1]. Debdiff is attached.
All tests ran successfully. Please review.
- -abhijith
[1]
https://mentors.debian.net/debian/pool/main/g/graphite2/graphite2_1.3.10
- -1~deb7u2.dsc
-BEGIN PGP SIGNA
Hugo Lefeuvre writes:
> So, after some debugging on CVE-2018-7456, I start to get the feeling to
> understand the issue.
>
> Here are my conclusions for the moment:
>
> * In any case, the transfer function should not care about other
> channels defined by ExtraSamples (see 2nd and 3rd paragraph
Hugo Lefeuvre writes:
> Sure ? To me it looked like three entries are provided, but the fourth
> (td->td_transferfunction[3]) isn't.
I was about to write justification for how I was absolutely sure of
this.
Then I realized the loop is:
for (i = 1; i < td->td_samplesperpixel; i++)
i.e. it star
Hugo Lefeuvre writes:
> So, in fact it may very well be that the size of the TransferFunction table
> is always at most 3 rows and this definition is right.
Is the code that loads the transfer function safe? Is there any
possibility of tricking the loading function to try and set the 4th row?
--
So, after some debugging on CVE-2018-7456, I start to get the feeling to
understand the issue.
Here are my conclusions for the moment:
* In any case, the transfer function should not care about other
channels defined by ExtraSamples (see 2nd and 3rd paragraphs of
TransferFunction entry, page
