Re: BUG: possible memory leak in userspace libauparse

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.