Hi all
I think there is a memory leak bug in userspace audit, correct me if I’m wrong. Audit-2.8.5 has introduced a performance improvement for lol operations(see the following commits for details:3ecf7a212c53e439109163eef79e3bbe4c00dd99,
270c39f1f0dd783a32aa0f9a73214cf15e1c19b4). The improvement code snippet is repeated here for your convenience:
auparse/auparse.c:
260 if (lowest && lowest->status == EBS_COMPLETE) {
261 lowest->status = EBS_EMPTY;
262 au->au_ready--;
263 // Try to consolidate the array so that we iterate
264 // over a smaller portion next time
265 if (lowest == &lol->array[lol->maxi]) {
266 au_lolnode *ptr = lowest;
267 while (ptr->status == EBS_EMPTY && lol->maxi > 0) {
268 lol->maxi--;
269 ptr = &lol->array[lol->maxi];
270 }
271 }
272 return lowest->l;
273 }
The problem is that after shrinking lol-maxi, the EBS_EMPTY lolnodes are effectively denied chances of being freed, as only entries below lol-maxi are freed:
1405 for (i = 0; i <= au->au_lo->maxi; i++) {
1406 au_lolnode *cur = &au->au_lo->array[i];
1407 if (cur->status == EBS_EMPTY && cur->l) {
1408 #ifdef LOL_EVENTS_DEBUG01
1409 if (debug) {printf("Freeing at start "); print_list_t(cur->l);}
1410 #endif /* LOL_EVENTS_DEBUG01 */
1411 aup_list_clear(cur->l);
1412 free(cur->l);
1413 au->le = NULL; // this should crash any usage
1414 // of au->le until reset
1415 cur->l = NULL;
1416 }
1417 }
The problem is further confirmed when later insertions can make the cut out entries completely lost to the wild, since it doesn’t check cur->l:
199 for (i = 0; i < lol->limit; i++) {
200 au_lolnode *cur = &lol->array[i];
201 if (cur->status == EBS_EMPTY) {
202 cur->l = l;
203 cur->status = EBS_BUILDING;
204 if (i > lol->maxi)
205 lol->maxi = i;
206 return cur;
207 }
208 }
---------------------------------------------Some blackbox tests on sedispatch:-------------------------------------------------------
Valgrind check reports memory leak problem:
==30536== LEAK SUMMARY:
==30536== definitely lost: 14,848 bytes in 232 blocks
==30536== indirectly lost: 781,160 bytes in 29,837 blocks
==30536== possibly lost: 0 bytes in 0 blocks
==30536== still reachable: 11,851 bytes in 81 blocks
==30536== suppressed: 0 bytes in 0 blocks
==30536== Reachable blocks (those to which a pointer was found) are not shown
And a dummy test program generating floods of AVC events can blow the sedispatch daemon to some hundreds of megabytes after running for several days.