From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: BUG: possible memory leak in userspace libauparse Date: Tue, 26 Mar 2019 17:31:22 -0400 Message-ID: <33060019.EIo9FJMi9Z@x2> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: Shanshishi List-Id: linux-audit@redhat.com 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.