v3.1-experimental branch -- multiple memory leaks

[martinhsv]

Within current v3/dev/3.1-experimental, I believe I have identified some additional memory leaks that have not yet been addressed:

1. set_env.cc:41
2. modsec_build.cc:30
3. validate_dtd.cc:52 (this one may be a false positive -- needs more investigation)

[zimmerle]

set_env

I believe you are referring to:

https://github.com/SpiderLabs/ModSecurity/blob/afefda53c69bb17e2ec16d24dd6fbc2c8fd7d063/src/actions/set_env.cc#L40

Is it a consequence of strdup? that was used to set the variable. It is gone when the process exit.

modsec_bulid

Duplicate as the memory leak reported on #2376. Fixed.

Here the variable is generated:
https://github.com/SpiderLabs/ModSecurity/blob/afefda53c69bb17e2ec16d24dd6fbc2c8fd7d063/src/variables/modsec_build.cc#L31

Here is the constructor for VariableValue:
https://github.com/SpiderLabs/ModSecurity/blob/5f38e37f73f151db49e3f34981adc96d03633889/headers/modsecurity/variable_value.h#L98-L108

validate_dtd

https://github.com/SpiderLabs/ModSecurity/blob/afefda53c69bb17e2ec16d24dd6fbc2c8fd7d063/src/operators/validate_dtd.cc#L51-L53

Is it the right place?

[martinhsv]

set_env.cc: Perhaps I'm misunderstanding you but waiting for the process to terminate doesn't help here. Because the memory allocation is occurring in the execute function, this is a per-transaction leak.

[martinhsv]

modsec_build.cc: Yes, the heap memory allocation is happening in that particular VariableValue constructor. And it is due to the line with that push_back in modsec_build.cc.

But, like the previous case, because this is occurring within the evaluate function, this is a per-process leak.

[martinhsv]

validate_dtd:

No, it's at validate_dtd.cc:52 (line number from 3.1-experimental):

m_dtd = xmlParseDTD(NULL, (const xmlChar *)m_resource.c_str());

I haven't fully confirmed this one, but I believe this is the same sort of issue; this line of code is in the evaluate function which means it runs every transaction and overwrites the the previous value of the pointer m_dtd. Which means that the memory that had been pointed to is leaked on a per-transaction basis.

[martinhsv]

None of the above were already fixed in 3.1-experimental when I ran the tests on Friday -- I did make sure to run against the current revision of 3.1-experimental as of that date.

[WGH-]

In glibc, setenv seems to behave better wrt memory management, as it tries to reuse the KEY=VALUE pairs if possible. But it will still leak memory if called with different arguments, and nothing can be done to prevent this.

What's the use case for the setenv operator, anyway? Manipulating the global process state from transaction handling code seems like a bad idea.

[tomasdeml]

FYI #2381 (comment)

[martinhsv]

Regarding the 2nd of 3 leaks reported in this issue (i.e. modsec_build), as stated

modsec_bulid

Duplicate as the memory leak reported on #2376. Fixed.

Confirmed. No further work required for this one.

[martinhsv]

Adding an additional one:

4. validate_schema.cc:85

This is structurally similar to the previous-reported validate_dtd.cc leak, and is likewise a per-transaction memory leak

    m_validCtx = xmlSchemaNewValidCtxt(m_schema);