BUG: possible memory leak in userspace libauparse
Steve Grubb
sgrubb at redhat.com
Tue Mar 26 21:31:22 UTC 2019
On Monday, March 25, 2019 10:38:02 PM EDT zhangqi (DI) wrote:
> I think there is a memory leak bug in userspace audit, correct me if
> I'm wrong.
Thanks for reporting this. Upstream commits 1af601f and a4ed200 fix this.
-Steve
> 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.
More information about the Linux-audit
mailing list