linux-kernel - Re: [PATCH] mm: kmemleak: Fix crashing during kmemleak disabling

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: <20150603162936.9132276820819001436585b3@linux-foundation.org>
Date:	Wed, 3 Jun 2015 16:29:36 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Vignesh Radhakrishnan <vigneshr@...eaurora.org>
Subject: Re: [PATCH] mm: kmemleak: Fix crashing during kmemleak disabling

On Wed,  3 Jun 2015 16:42:56 +0100 Catalin Marinas <catalin.marinas@....com> wrote:

> With the current implementation, if kmemleak is disabled because of an
> error condition (e.g. fails to allocate metadata), alloc/free calls are
> no longer tracked. Usually this is not a problem since the kmemleak
> metadata is being removed via kmemleak_do_cleanup(). However, if the
> scanning thread is running at the time of disabling, kmemleak would no
> longer notice a potential vfree() call and the freed/unmapped object may
> still be accessed, causing a fault.
> 
> This patch separates the kmemleak_free() enabling/disabling from the
> overall kmemleak_enabled nob so that we can defer the disabling of the
> object freeing tracking until the scanning thread completed. The
> kmemleak_free_part() is deliberately ignored by this patch since this is
> only called during boot before the scanning thread started.

I'm having trouble with this.  afacit, kmemleak_free() can still be
called while kmemleak_scan() is running on another CPU. 
kmemleak_free_enabled hasn't been cleared yet so the races remain.

However your statement "if the scanning thread is running at the time
of disabling" implies that the race is between kmemleak_scan() and
kmemleak_disable().  Yet the race avoidance code is placed in
kmemleak_free().

All confused.  A more detailed description of the race would help.

Also, the words "kmemleak would no longer notice a potential vfree()
call" aren't sufficiently specific.  kmemleak is a big place - what
*part* of kmemleak are you referring to here?

Finally, I'm concerned that a bare

	kmemleak_free_enabled = 0;

lacks sufficient synchronization with respect to the
kmemleak_free_enabled readers from a locking/reordering point of view. 
What's the story here?

--
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/