Bug 160392 - Memory Leak in autofs
Memory Leak in autofs
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeffrey Moyer
Brian Brock
:
Depends On:
Blocks: 156320
  Show dependency treegraph
 
Reported: 2005-06-14 16:56 EDT by Tom Kincaid
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2005-663
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-28 11:22:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Kincaid 2005-06-14 16:56:02 EDT
In trying to reproduce another bug, I managed to uncover a memory leak in
autofs.  The test case is as follows:

setup autofs with a timeout of 1 second
run the following shell script in two xterms:

#!/bin/sh
while true; do
        for n in `seq 1 48`; do
                ls /test/$n
        done
        sleep 2
done

watch the size-256 slab cache grow

Within 4 minutes, I had the size-256 cache grow to 384k.  With the patched
kernel, size-256 remained at 75 for 45 minutes (so far).

It's a fairly straight-forward fix.  If there are multiple events for a
single path, say two processes doing an ls of a not-yet-mounted directory,
then they will share a wait queue.  from fs/autofs4/waitq.c:autofs4_wait

	name = kmalloc(NAME_MAX + 1, GFP_KERNEL);
	if (!name)
		return -ENOMEM;
	...

	if ( !wq ) {
		/* Create a new wait queue */
		wq = kmalloc(sizeof(struct autofs_wait_queue), GFP_KERNEL);
		if ( !wq ) {
			kfree(name);
			up(&sbi->wq_sem);
			return -ENOMEM;
		}
		...
		wq->name = name;

		...
	} else {
		atomic_inc(&wq->wait_ctr);
		up(&sbi->wq_sem);
		...
       }

In the else clause, we forget to free the name we kmalloc'd above.  This is
pretty easy to trigger, and could be considered a DOS, I think.  Note that
the default timeout for automount is 60 seconds.  As such, it would take
quite some time to render a system useless in this manner.

-Jeff



--- linux-2.4.21/fs/autofs4/waitq.c.orig
+++ linux-2.4.21/fs/autofs4/waitq.c
@@ -226,6 +226,7 @@ int autofs4_wait(struct autofs_sb_info *
 	} else {
 		atomic_inc(&wq->wait_ctr);
 		up(&sbi->wq_sem);
+		kfree(name);
 		DPRINTK(("autofs4_wait: existing wait id = 0x%08lx, name = %.*s, nfy=%d\n",
 			(unsigned long) wq->wait_queue_token, wq->len, wq->name, notify));
 	}
Comment 1 Ernie Petrides 2005-06-14 17:30:41 EDT
A fix for this problem was committed to the RHEL3 U6 patch
pool on 20-Apr-2005 (in kernel version 2.4.21-32.1.EL).

Comment 7 Ernie Petrides 2005-09-19 16:37:37 EDT
*** Bug 150209 has been marked as a duplicate of this bug. ***
Comment 8 Red Hat Bugzilla 2005-09-28 11:22:26 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-663.html

Note You need to log in before you can comment on or make changes to this bug.