BUG: possible memory leak in userspace libauparse

zhangqi (DI) zhangqi144 at huawei.com
Tue Mar 26 02:38:02 UTC 2019


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20190326/bc245e68/attachment.htm>


More information about the Linux-audit mailing list