linux-kernel - Re: OOM triggered with plenty of memory free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130321070750.GV30145@marvin.atrad.com.au>
Date:	Thu, 21 Mar 2013 17:37:50 +1030
From:	Jonathan Woithe <jwoithe@...ad.com.au>
To:	Raymond Jennings <shentino@...il.com>
Cc:	Hillf Danton <dhillf@...il.com>,
	David Rientjes <rientjes@...gle.com>,
	Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Jonathan Woithe <jwoithe@...ad.com.au>
Subject: Re: OOM triggered with plenty of memory free

On Sat, Mar 16, 2013 at 02:33:23AM -0700, Raymond Jennings wrote:
> Anyway, to the parent poster, could you tell us more, such as how much
> ram you had left free?

Following on from my previous post, here is a summary of what I know about
this memory leak following additional testing.
 * It was introduced in 2.6.35.11
 * It was not present in 2.6.35.12
 * Previous git bisects on the main git tree indicate that the leak was
   not in 2.6.36 or any later mainline kernel version

Commit cab9e9848b9a8283b0504a2d7c435a9f5ba026de to the stable tree ("scm:
Capture the full credentials of the scm sender") seems to have introduced
the leak.

Commit 48e6b121605512d87f8da1ccd014313489c19630 to the stable tree ("Fix
cred leak in AF_NETLINK") seems to have fixed the leak in the stable branch. 
The commit message concentrates on the closure of an information leak, but
evidently there was a memory leak behind it as well.

cab9..26de was upstreamed as 257b5358b32f17e0603b6ff57b13610b0e02348f, but
48e6..9630 does not appear to have made it into mainline in its entirety.
However, the call to scm_destroy() in the "out:" block added by 48e6..9630
is in mainline; I presume that this is what closes the memory leak because
the only other parts of the commit set the function return value (unless the
different function returns cause the callers not to leak).

I'm guessing that 48e6..9630 was not applied to mainline in its
entirety due to the underlying problem being fixed in a slightly different
way.

Regards
  jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/