Memory leak parsing/relaying from detail files?

[Arran Cudbard-Bell]

> On 8 Mar 2016, at 00:10, Nathan Ward <lists+freeradius at daork.net> wrote:
> 
> Hi,
> 
> I am working through debugging a memory leak I am hitting, and I think I have found the culprit.

Yeah looks broken in v3.1.x too, good catch/sleuthing.
> 
> The trigger appears to be a malformed NAS-IPv6-Address attribute coming from a Cisco ASR9000, and I will certainly contact the vendor, however it occurs to me that we should work to solve this in FreeRADIUS as well.

Yes.

> I have two questions:
> 1) Can I filter this out in some way that I am unaware of as a short term fix?

Not in this case no. This particular type of unknown (malformed) attribute is invisible to the policy language. You might have some success with the attr_filter module, but you'd need to list all the attributes you wanted to keep.

> 2) I would like to figure out this memory leak myself and submit a patch, but I’m not sure how this part of the code works. I *think* that this should be freed after being proxied to the backend server - so, perhaps in process.c somewhere after a packet is sent, it should have any vp das that have is_unknown set to true freed? I’m not clear to me what impact that would have on other bits of code.

The lifetime of the unknown attribute should be tied to the VALUE_PAIR it was created for and that's not being done. I'm not sure those functions are correctly structured.

Will review tomorrow unless Alan D gets there first.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20160308/869f3d46/attachment.sig>