Thanks Andrew!

I've re-built with your recent commits and it seems that your efforts have solved the issue.

I've run for a few hours and the memory consumption doesn't rise :)

Regards,

Erik

On 2017-03-02 22:30, Andrew Cagney wrote:
I didn't do any archaeology

I think two things were at play.

The first change:

commit 02768e7cd76a465443f13f3cbf6864db268f0b52
Date:   Mon Nov 12 21:18:54 2007 -0500

    #845 - beginning of DH calculation and SKEYSEED derivation.

would copy skeyseed into a wirechunk:

    setwirechunk_fromchunk(skr->skeyseed, skeyseed, skr);

but never copied the field back out.  This set the trap.
(I suspect this was ok as deleting the wirechunk SKR would reclaim the memory).

The second change:

commit 944c9a31c1e4dff1ab92cdf9c85629b7270a6157
Date:   Tue Feb 18 04:15:35 2014 -0500

    smoother nss:
    Many NSS pointers were passed through chunks making to code confusing
    and brittle.  No longer.
    A side-effect is that this change makes it harder to ditch NSS.

replaced the wirechunk with individual pointer moves.  Since the old
code didn't extract the field skeyseed, the new code didn't either;
falling into the trap :-)

I've pushed a fix.  For 3.19, something like:

@@ -143,6 +142,7 @@ static void calc_skeyseed_v2(struct pcr_skeyid_q *skq,
        PK11SymKey *finalkey = ikev2_ike_sa_keymat(skq->prf, skeyseed_k,
                                                   ni, nr, spii, spir,
                                                   total_keysize);
+       free_any_symkey("skeyseed_", &skeyseed_k);

        size_t next_byte = 0;

might be sufficient (but I've not tested it).

Andrew

_______________________________________________
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev

Reply via email to